-
Notifications
You must be signed in to change notification settings - Fork 40
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
Bloated dist #40
Comments
The initial idea was to make an easy web form renderer with different types of fields manageable using a JS object. Your idea of splitting the package is a very good, but one which we cannot get into immediately due to lack of time. It might be a while before I am able to do the split myself. |
I have been thinking about making this a monorepo and having separate packages for core and the form related elements. I was thinking of splitting it as follows:
This would allow us to add react-native support with separate packages for native fields. You keep the dependencies to a minimum by requiring only what you want. Any thoughts? |
sounds awesome. This way the user could load in one project formik-json, field-dom, react-select and the container-dom stuff. and pass them as conf options to formik-json. In another project one could juse use formik-json together with container-react-native and other react-native fields. It will both help with reducing the size of the package and making it more reusable. |
Were you thinking Lerna? |
Yes I was thinking Lerna |
Not sure if this is a bug, or a feature request. I just realized that our bundle size exploded with 200kb after adding formik-json package.
By the look of it - I initially thought it is lodash. I replaced all calls to lodash with calls to lodash-es, but this actually didn't help with the size.
Then I looked further and it seems that the biggest problem is the quill and react-select renderers.
What is your goal with formik-json? I don't think that we'll ever use the quill component and right now I'm finding myself in a situation where I don't use any of the provided renderers.
Are there any plans to split the renderers from the package and have them in separate repositories and then everyone can register the renderers that are needed on per project basis?
The text was updated successfully, but these errors were encountered: