-
Notifications
You must be signed in to change notification settings - Fork 16
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
Updates to model or form data should be reflected in the form (data binding) #9
Comments
I'll pick up this one next... |
I'd say the priority with the work item is to support "Data Down", meaning changes to the base model should be reflected in the UI. I think we should de-emphasize "Data Up", meaning changes that the user makes on the form are not automatically set to the model, but rather require an action. I'm currently working on issue #21 where I'll give the ability for the caller to provide a change action for this. Another possibility would be to look into supporting the mut helper, though the thoughts? @jeremywrowe @cliffpyles @samchrisinger ? |
Definitely in favor of single-directional binding here as it provides a looser coupling between the parent component/controller and the dynamic-form child. I'm not an Ember pro by any means, but the pattern of passing an action down to a child component seems very common. Additionally this could have the benefit that the parent controller/component get's a stronger guarantee that it's state is only being updated with valid data (i.e. the dynamic form component runs all of it's validations, and only notifies the parent if there are no errors). |
This is what I'm working on and hope to have this deployed within a week: |
Cutting a release this weekend where the data param takes ember objects. I had more trouble updating alpaca forms external to the form. It looks like while we use alpaca, I'm going to have to do something that uses observers to listen for data changes and then programmatically update the rendered alpaca objects. I started a branch for this but will probably treat it as a lower priority until a find out about someone who wants to update form values external to the form. In the meantime like I said we do now support ember objects as data (starting and 0.0.9), so things like computed properties are now honored. |
Hey @toddjordan, My schema changes dynamically based on a users input, I need my form to rerender based on when the schema changes, any idea how i could do that? |
Hi @Rytiggy The schema is rendered in the component's didReceiveAttrs hook, which runs when the component is initially rendered. We could add some functionality to add a didUpdateAttrs hook that ill re-create and render the schema when that specific attribute is updated. Feel free to submit a PR if you want to play with it and get it going. Let me know if you have questions. |
@toddjordan afik I'm wondering if it's reasonable to refactor the rendering code from |
yes, I think that would make sense. try it out and if it works for you we can incorporate it. We should probably save the renderer object as an instance variable on the component and then just call |
WIP PR here: #37. Still working through some integration tests... probably not going to happen today, but hopefully soon. |
awesome! Will take a look this afternoon/evening. Hoping to get some time in the next week to work on rendering ember components as well B-) |
If form values are updated outside the dynamic form, the form should recognize this and rerender or update its values accordingly.
We should have a separate attribute to provide data, with the assumption that data will be stored and handled separately from schema.
where the data object has keys that match the ids of each item defined by the schema
When the data object is updated, the dynamic form component should be re-rendered and display the new values.
The text was updated successfully, but these errors were encountered: