Skip to content
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

Om Next support? #4

Open
Driphter opened this issue Aug 25, 2017 · 3 comments
Open

Om Next support? #4

Driphter opened this issue Aug 25, 2017 · 3 comments

Comments

@Driphter
Copy link

Any chance of Om Next support being implemented?

@pablinos
Copy link

I'd be interested in this too. I wonder how hard it would be? Looking at how the Reagent and Rum components are defined there's a macro that builds them and is mapped to the collection of antd components.

It might be easier than we think?!?

@priornix
Copy link
Owner

priornix commented Aug 13, 2018

Actually @sctianwei (thanks!) has done some work on adding Om Next support here:

sctianwei@5247fcc

However, I noticed that there's an issue. It seems like the antd library's getFieldDecorator function is not actually being called. Hence the components (eg: text input) are not clickable, until the following function is called on on-change.

(defn handle-fields-change[comp]
  (om/update-state! comp assoc :form (ant/get-form comp)))

This workaround works, but it can be error-prone since you have to call it for all the form controls and I have not tested enough to see if there are any other unexpected behaviour.

@sctianwei Could you explain what led you to do the workaround above? Thanks!

@sctianwei
Copy link
Contributor

@priornix it's not the final solution, I do this only want the form can just work.
actually, I've done some debug, the getFieldDecorator get called, the value changed at first, but somehow it get reverted after re-rending.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants