Where to call server api about uniflow-polymer HOT 4 CLOSED

Good question, thank you. Calls to the server should only be put in action dispatchers, one [almost] never should make server calls from visual elements. Validation feature in model view is intended for client side validation. For persisting the data and server validation error I would recommend the following approach:

• create action dispatcher for server calls. For example, SAVE_DATA is the action that would trigger validation and saving. Create [SAVE_DATA] method to make a server call. Program the method to emit DATA_SAVED action in case of success or INVALID_DATA in case of validation errors.
• in your view action dispatcher create handlers for DATA_SAVED and INVALID_DATA actions. Then handler for DATA_SAVED may trigger routing to the new screen, whereas handler for INVALID_DATA would update status.validation property with error messages and invalid flags.

from uniflow-polymer.

So the visual element calls the Model validation and if it passes, emits SAVE_USER. A <user-action-dispatcher> calls the backend API and handles the Promise. On success emits SAVE_USER_SUCCESS and failure SAVE_USER_FAILED. In a different action dispatcher we handle the SAVE_USER_SUCCESS and SAVE_USER_FAILED events.

This is a very similar workflow to what I am doing but I'm using the Polymer listeners to listen for the custom events fired. In one scenario the SAVE_USER functionality would be used from multiple pages. There might be a User Admin section to add and edit users and also a User Profile page that lets you modify yourself. Both use the same form and logic so both would call SAVE_USER.

I'm currently handling that using the Polymer listeners in a parent page that embeds the <myapp-user-edit> component which is the form and logic to call SAVE_USER. That way a success can redirect to the proper place depending on if it was used from the User Admin screen or from the User Profile screen.

I'm guessing that translates to putting a <user-admin-action-dispatcher> in the User Admin parent page and a <user-profile-action-dispatcher> in the User Profile parent page. Then each one can handle the SAVE_USER_SUCCESS differently. Does that sound about right?

from uniflow-polymer.

All action dispatchers exist at the application level. It's up to the developer to logically associate action dispatchers with views, UniFlow doesn't prescribe one specific way. What we do in our project is setting extra options for actions; that gives you various options. Some action dispatchers may always process certain actions, some are conditional. For instance, in your scenario you may have view action property and make call as follows:
this.emitAction({ type: 'SAVE_USER', view: 'profilePage' }
Then user-profile-action-dispatcher will pick up the success action that has view set to "profilePage". You just need to make sure that your service action dispatcher passes through the options it receives to success/failure actions.
This is one of many ways to handle this scenario. Once again, there's no single preferred way.

from uniflow-polymer.

Thanks. I just installed and am going to be testing out things today. Uni-flow is more straightforward and "Polymer-ish" than my existing method.

from uniflow-polymer.