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

Updates to model or form data should be reflected in the form (data binding) #9

Open
toddjordan opened this issue Dec 24, 2015 · 11 comments
Assignees

Comments

@toddjordan
Copy link
Owner

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.

{{dyanamic-form schema=schemaObj data=dataObj}}

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.

@toddjordan toddjordan self-assigned this Jan 5, 2016
@toddjordan
Copy link
Owner Author

I'll pick up this one next...

@toddjordan
Copy link
Owner Author

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 this.attrs convention may not be stabilized until glimmer 2.

thoughts? @jeremywrowe @cliffpyles @samchrisinger ?

@samchrisinger
Copy link
Contributor

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).

@toddjordan
Copy link
Owner Author

This is what I'm working on and hope to have this deployed within a week:
Today we work if you pass a plain JavaScript Object { } as the data argument.
I will also support passing an ember object, whether it be an Ember.Object, or a DS.Model. Properties will be accessed from these objects using get so things computeds can be honored.

@toddjordan
Copy link
Owner Author

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.

@Rytiggy
Copy link

Rytiggy commented Jul 12, 2016

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?

@toddjordan
Copy link
Owner Author

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.

See https://github.com/toddjordan/ember-cli-dynamic-forms/blob/master/addon/components/dynamic-form.js#L32-41

Feel free to submit a PR if you want to play with it and get it going. Let me know if you have questions.

@samchrisinger
Copy link
Contributor

@toddjordan afik didRecieveAttrs runs any time a component receives new attributes. This can be at instantiation or later in the component's lifecycle. So we're noticing that didRecieveAttrs does fire when schema is updated, but the Alpaca form never get's re-rendered (looks like rendering happens in didInsertElement?).

I'm wondering if it's reasonable to refactor the rendering code from didInsertElement into a helper and then actually triggering an Alpaca rerender if the schema is changed?

@toddjordan
Copy link
Owner Author

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 this.get('renderer').render(this.get('renderSchema'), this.$()); in didReceiveAttrs

@samchrisinger
Copy link
Contributor

WIP PR here: #37. Still working through some integration tests... probably not going to happen today, but hopefully soon.

@toddjordan
Copy link
Owner Author

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-)

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

3 participants