feat: Basic CRUD for userData structure, setup ListContext
#3198
Conversation
|
Removed vultr server and associated DNS entries |
DafyddLlyr
force-pushed
the
dp/list-user-data
branch
3 times, most recently
from
421bf70 to
a3a6021
Compare
| schema, | ||
| }) => { | ||
| const [activeIndex, setActiveIndex] = useState<number | undefined>(0); | ||
| const [userData, setUserData] = useState<UserData>( |
There was a problem hiding this comment.
I'm still not 100% sure how this will interact with a Fromik instance, so this may get updated in the next PR to either be just be Fromik state, or this can be generated by Formik.
I've intentionally avoided this in the current PR to keep thing separate and as small as possible, even if it may mean a little more "churn".
DafyddLlyr
force-pushed
the
dp/list-user-data
branch
from
a3a6021 to
8024a3f
Compare
| // Button is present allow additional items to be added | ||
| const addItemButton = getByRole("button", { | ||
| name: /Add a new animal type/, | ||
| }); |
There was a problem hiding this comment.
nit: introducing & using a stable data-testid attribute for the addItemButton & similar early might mean less tedious updates based on "name" later and more generic tests independent of schemas?
There was a problem hiding this comment.
That's a great shout actually - will make that change 👍
There was a problem hiding this comment.
question: @jessicamcinchak what does "nit" mean?
There was a problem hiding this comment.
shorthand for "nit picky" ! opinionated minor suggestions basically, almost always non-blocking to overall approval and readiness to merge 🙂
There was a problem hiding this comment.
@RODO94 We talked about conventional commits for PR names as part of onboarding. Using nit/nitpick comes from conventional comments which we use here and there also 👍
| }} | ||
| > | ||
| {children} | ||
| </ListContext.Provider> |
What does this PR do?
ListContextto wrap components and share state and logicScreen.Recording.2024-05-28.at.13.03.39.mov
What's not in this PR?
Context / Design
I feel like one of the main pain points with the
FileUploadAndLabelcomponent was having a group of interdependent components which relied on a shared state in the "root" component. This wasn't a problem initially, but as things grew it got harder and harder to manage, and there's a lot of prop-drilling and derived state there. I've tried to anticipate this a little by setting up aReact.Contextto wrap these components. This also means co-location of logic, and separation from style/structure which is nice.Again, a lot of unfinished work and outstanding
TODOs in this PR!