You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, we use connect() to wire up components to Formik's context. This creates an extra node for <Field>, <Form>, and <FastField> because connect() is simply a wrapper around the <FormikContext.Consumer> render prop.
Desired Behavior
Remove connect() usage internally and instead use Andrew's forthcoming Context.unstable_read() (facebook/react#13139) which allows reading context within any render-phase function.
Suggested Solution
Pretty straight forward. We rename <XXXXImpl> to just <XXXX> and get rid of connect() usage internally (i.e. remove my poorly typed HoC TypeScript nonsense at the bottom of the files). We will still need interface FormikContext because I expect that the TS type signature for .unstable_read() will take a TS generic.
// Field.jsimportReactfrom'react'import{FormikContext}from'./FormikContext';exportconstField=({ component ='input', name, ...rest})=>{// Yes. This is real.const{ handleChange, handleBlur, values }=FormikContext.unstable_read();// handwaiving the rest...returnReact.createElement(component,{onChange: handleChange,onBlur: handleBlur,value: values[name]||'',
name,
...rest,});};
Who does this impact? Who is this for?
We will still export connect() so no breaking changes there. However, enzyme tests may break AGAIN because of these changes because we are going to be removing a node from the tree for each component (no more FieldImpl, just Field). 🤣 🤣. We can now go back to shallow rendering instead of mount though!
Additional context / Discussion
We may end up moving <Field> to an SFC and moving all the class functions down into render. I need to ask Dan/Andrew about pros / cons.
Decide if we should deprecate connect() with a warning, since this API will be the future.
Would be great to expose new "context getters" ™️ so that people don't even need <Field> to create their own custom components? I'm not sure where these would get defined? Maybe in getDerivedStateFromProps in Formik? idk. Need to ask.
The text was updated successfully, but these errors were encountered:
Hola! So here's the deal, between open source and my day job and life and what not, I have a lot to manage, so I use a GitHub bot to automate a few things here and there. This particular GitHub bot is going to mark this as stale because it has not had recent activity for a while. It will be closed if no further activity occurs in a few days. Do not take this personally--seriously--this is a completely automated action. If this is a mistake, just make a comment, DM me, send a carrier pidgeon, or a smoke signal.
Current Behavior
Currently, we use
connect()
to wire up components to Formik's context. This creates an extra node for<Field>
,<Form>
, and<FastField>
becauseconnect()
is simply a wrapper around the<FormikContext.Consumer>
render prop.Desired Behavior
Remove
connect()
usage internally and instead use Andrew's forthcomingContext.unstable_read()
(facebook/react#13139) which allows reading context within any render-phase function.Suggested Solution
Pretty straight forward. We rename
<XXXXImpl>
to just<XXXX>
and get rid ofconnect()
usage internally (i.e. remove my poorly typed HoC TypeScript nonsense at the bottom of the files). We will still needinterface FormikContext
because I expect that the TS type signature for.unstable_read()
will take a TS generic.Who does this impact? Who is this for?
We will still export
connect()
so no breaking changes there. However, enzyme tests may break AGAIN because of these changes because we are going to be removing a node from the tree for each component (no more FieldImpl, just Field). 🤣 🤣. We can now go back to shallow rendering instead of mount though!Additional context / Discussion
<Field>
to an SFC and moving all the class functions down into render. I need to ask Dan/Andrew about pros / cons.<Field>
to create their own custom components? I'm not sure where these would get defined? Maybe ingetDerivedStateFromProps
in Formik? idk. Need to ask.The text was updated successfully, but these errors were encountered: