Comments (4)
@chrisirhc let me run this idea past the other maintainers. Admittedly, I'm kinda against the idea, but I seemingly can't rationalize my thoughts other than "Oh god the types as-is are so complex I don't want to remove or touch them" but the more I think about it the more I realize this API would probably fix the types, not make them more complex.
Even so, I'm only human and the idea of throwing away a huge amount of work gives me a physical migraine haha.
from form.
After talking with @fulopkovacs, I don't think we're going to move forward with this API. Here's why:
- The lift of engineering would to refactor would be really heavy
name
doesn't resonate well with us when it's an array. We would typically rather the property then be calledaccessor
, but that introduces property name ambiguity (IE: Is this meant to be public or not?)- Like FS paths and URLs, there have to be some established patterns for our tooling to gather a basis on. While there's some arguments to be made to fix this; what about unicode characters or beyond? Should emoji be supported? (kinda joking, but there are semi-serious implications to this idea)
- We're struggling to think of many edgecases where
"
or\\
would be needed to support in an object's key name.
That said, we deeply appreciate your help figuring out our path and we may revisit this sometime in the future (say 2.0) if enough community feedback indicates that this is something they're wanting.
Moreover, we suggest that instead of backticks and hard-to-read name
properties, you might instead transform the object key-by-key (or with a utility to rename _
to .
maybe) to solve this problem.
Thanks (and sorry) once again 😄
from form.
After investigating the implementation, how open would you be to accepting a path array (tuple, in TypeScript terms) as an argument?
Using a string to represent these escaped field names is not "full-proof" since there'll always be something that may need some form of escaping or a character that we pick that we need to treat specially. This increases complexity on the TypeScript utility functions significantly.
I see that we're already converting these some.path
expressions to an array like ['some', 'path']
. Would you be open to accepting the array itself? That way we leave it to the user to pass the path which can contain any form of special characters that the TypeScript utilities as well as the makePathArray functions don't need to handle.
Here are some examples of proposals and what their field name
could look like:
Object | Today | Quoting the expression | Escaping the dot | Using a path array (tuple) |
---|---|---|---|---|
{'field': ''} |
'field' |
|||
{'.dot': ''} |
❌ | '[".dot"]' |
'\\.dot' |
['.dot'] |
{'.dot"quote': ''} |
❌ | ❌ | '\\.dot"quote' |
['.dot"quote'] |
I do like today's fieldApi name type-checking in that one field can only be specified in one way. I don't like to introduce multiple ways of specifying a field (e.g. accepting 'field'
, '["field"]
, "['field']"
). But... here we are.
from form.
No worries, sounds good. I think I understand where you're coming from.
I've gone a few times back and forth on this idea myself. I also don't like the idea of throwing away work. Will wait to hear back. 👍
from form.
Related Issues (20)
- Calling `createFormFactory<FormData>` and using a validator adapter throw TS errors HOT 1
- onChangeAsyncDebounceMs not properly debouncing HOT 1
- TanStack/Angular - Error when resetting the form HOT 1
- Missing error when validating via form options instead of via field HOT 3
- Factory `onSubmit` function not invoked whenever factory.useForm gets provided with `onSubmit` itself HOT 2
- Unable to read properties in nested array table HOT 2
- Nested Values Disappear when using StrictMode HOT 5
- onMount Error is not revalidated when the user changes the input HOT 2
- server actions example errors when using zod adapter HOT 1
- Cannot infer types on arrays of union of objects HOT 2
- Moving subfields of array field mix their values HOT 1
- Bad performance with 100+ rows in an array field HOT 4
- insertFieldValue replaces item instead of adding a new one and shift existing items
- solid form createField failed to import `memo` from "solid-js/web" when used in solid-start ssr mode HOT 1
- Issue with array + react + numbers HOT 2
- Nested Values Disappear when using StrictMode and `pushValue` HOT 1
- Incorrect field.state.value type HOT 5
- Server Actions example leaks backend code HOT 1
- Example for array usage lacks mode="array" HOT 1
- `canSubmit` is always `true` on first render of form
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from form.