Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Type-safe safeValue #58

Open
nighca opened this issue Nov 23, 2021 · 4 comments · May be fixed by #80
Open

Type-safe safeValue #58

nighca opened this issue Nov 23, 2021 · 4 comments · May be fixed by #80
Assignees
Labels
enhancement New feature or request

Comments

@nighca
Copy link
Collaborator

nighca commented Nov 23, 2021

safeValue is like $ of FieldState in formstate-x v2, while with some differences:

  1. Naming as safeValue (or something else) instead of $
  2. All states (including FormState, ArrayFormState, etc.) will provide safeValue
  3. It should be type-safe (deciding by validators - they may narrow type of value)
@nighca
Copy link
Collaborator Author

nighca commented Nov 23, 2021

@nighca
Copy link
Collaborator Author

nighca commented Nov 23, 2021

Some ideas:

1. Auto type inference by validators

const state = new FieldState<string | null>('').validators(notNull) // safeValue: string

It's hard, maybe impossible

2. Generic type passing with validator

const state = new FieldState<string | null>('').validators<string>(notNull) // safeValue: string

3. Generic type passing with constructor

const state = new FieldState<string | null, string>('').validators(notNull) // safeValue: string

4. Type assertion while read safeValue

const state = new FieldState<string | null>('').validators(notNull)
const safeValue = state.safeValue! // string

This is not real "type-safe"..

@nighca nighca linked a pull request Mar 19, 2022 that will close this issue
@nighca nighca self-assigned this Apr 18, 2022
@nighca nighca added the enhancement New feature or request label Apr 18, 2022
@mattleonowicz
Copy link

One thing to consider: should this value be defined and available even when validators return errors?
If not, then 2. makes sense.

But if this value is always defined, regardless of latest validation result, then I would suggest not linking the safeType with validators as in 2.

@nighca
Copy link
Collaborator Author

nighca commented May 12, 2022

One thing to consider: should this value be defined and available even when validators return errors?

Accessing safe-value will throw if currently validation not passed.

@computed get safeValue() {
  if (!this.validated || this.hasError) throw new Error('TODO')
  return this.value
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants