feat: List component - basic model, types & UI #3197
Conversation
|
Removed vultr server and associated DNS entries |
| type={((type) => { | ||
| if (type === "email") return "email"; | ||
| else if (type === "phone") return "tel"; | ||
| return "text"; | ||
| })(data.type)} | ||
| multiline={data.type && ["long", "extraLong"].includes(data.type)} |
There was a problem hiding this comment.
There's some repeated code here from existing components.
I'm hoping that once error handling / form values are handled I can DRY this up a little with more generic, shared, input components.
| @@ -169,7 +170,7 @@ const Node: React.FC<any> = (props: Props) => { | |||
| return <FindProperty {...allProps} />; | |||
|
|
|||
| case TYPES.List: | |||
| return <List {...allProps} />; | |||
| return hasFeatureFlag("LIST_COMPONENT") ? <List {...allProps} /> : null; | |||
There was a problem hiding this comment.
Moving this here means I can escape the "don't use conditional hooks" warning.
Docs: https://react.dev/reference/rules/rules-of-hooks#only-call-hooks-at-the-top-level
| }) { | ||
| return ( | ||
| <Root htmlFor={props.htmlFor}> | ||
| <Root htmlFor={props.htmlFor} id={props.id}> |
There was a problem hiding this comment.
This was necessary due to how MUI handles linking a label to the <Select/> component.
Helpfully, without this fix, the a11y unit test was failing 🧪
As this is our first user facing Select I think there's likely some work in getting this to work as expected with our existing components and styles perfectly - what I have here is a little rough and ready, but will be revisited once it's wired up to a form.
Docs: https://mui.com/material-ui/react-select/#accessibility
| /> | ||
| <ListCard> | ||
| <Typography component="h2" variant="h3"> | ||
| {schema.type} index |
There was a problem hiding this comment.
index will be replaced by a number once I've setup user data in state.
| // TODO: Track "active" index | ||
| // TODO: Validate min / max | ||
| // TODO: Validate user input against schema fields, track errors | ||
| // TODO: On submit generate a payload |
| ], | ||
| min: 1, | ||
| max: 10, | ||
| } as const; |
There was a problem hiding this comment.
schema definition files feel like a good MVP route here & editable by someone like August in very near future until more general editor customisation is possible ➕
|
Thanks for the speedy review @jessicamcinchak - appreciate it! 👍 |
What does this PR do?
Listcomponenttest.todos()What's not in this PR?
A whole lot! The plan is to split these next steps into smaller, atomic PRs across the course of this week. This PR so already >500 LOC so this seems like a sensible point to stop off.
I'm aware there's a fair number of outstanding TODOs left throughout this PR - I hope you'll forgive this for a WIP feature still behind a feature flag 👍
Upcoming PRs
Context / Principles
Here's a high-level overview of what I'm hoping to achieve here -
Schemas
Right now, this is a typed object living in the codebase - see the example
Zoo.ts. This allows us to write a.tsfile, but not worry about a complex Editor form to create this just yet. In future, we can allow greater customisation and control over the generation of these but we're taking a pragmatic approach here for now.UI / UX
The types used in the
Schematype are those already used in out UI components. This means we get a consistent interface and behaviour across our frontend.Form Validation / Error handling
I'm going to try to generate a dynamic Yup schema / Formik instance based on the schema set up in the Editor. This should mean I can re-use a lot of already tested code validating user inputs. A few options to be explored here if this isn't a viable option.
Payload
When a user submits the form, we can take their responses and map them in the passport based on the
fnvalues supplied in the schema. This will then be referenced inplanx-coreto create the required payload for a valid ODP schema (e.g. Residential units).