-
-
Notifications
You must be signed in to change notification settings - Fork 17
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
Material UI #53
Comments
There is already the types abstraction that lets you add new types and replace the default fields using the These fields could even be integrated (with a PR) in Formol with an aliased type: I don't think making default fields composable would be great since there's very few code in the basic fields and for more complicated fields you will need to write specific compatibility code anyway. |
Cool thanks. I tried to do the same also with material ui, but I had problems positioning the label. in material UI the basic I tried to override Field.jsx in my project, but failed. |
@paradoxxxzero @Gnilherk Now you just need to create your custom
and use that in your Field call:
Here is the PR: |
Thanks for the PR but wouldn't it be more simple to create a <Formol
types={{ text: InputField, select: SelectField }}
item={inputData}
onSubmit={onSubmit}
>
<MaterialField name="scenarioId" title="scenarioId" />
</Formol> As far as I can see if Formol exports its adapters (in particular the What I don't like is that it forces you to duplicate this logic: https://github.com/Kozea/formol/blob/master/src/Field.jsx#L10-L54 It may be better to add a new indirection between What do you think? |
@paradoxxxzero that was actually the approach that I initially took. So it does not work for Material UI. So the PR allows me to just override the render of the Field component, so all the individual fields can get rendered correctly.
Here is how the render of FieldMaterial.jsx looks like:
And here is the actual text field for Material UI, that uses the types override of the Formol component.
So to sum up - the Field.jsx now does add html (i.e. label) that is not needed and actually hinders UI libraries like Material UI and Polaris. Does that make sense? Maybe you have another idea on how to approach this issue. |
Component inheritance is widely not recommended so I don't think this is a good solution. But even in this case why can't you just inherit Field? @fieldPropsAdapter
export default class FieldMaterial extends Field {
...
} After giving it some thoughts, a cleaner solution would be a What do you think? |
I made a PoC implementation. Could you give it a look? Lines 82 to 85 in 358ebfc
(Async test snapshots are broken for some reasons) |
I really like your approach. Beeing a big fan of Autoform this looks very promising.
Do you plan to add an abstraction for base components? So that we could use different, already styled components form UI frameworks... I.E. Material UI?
Could I be of any help there?
The text was updated successfully, but these errors were encountered: