I am fairly new to Polymer, and only just studied how data binding works. I am porting an existing Dojo application, where there would be:
1) A single store (holding data) for each URL
2) A message from the server when a store element was updated
As a result, a dynamically made select box which depended on data in the store would automagically have an extra item if anywhere in the application a user added an item to the store (which held the data)
I am trying to replicate something like this in Polymer.
Use case: imagine an URL like this: /app/categories. By querying it with an HTTP GET, you end up with a JSON of all the categories available. While the app is running, the server might notify of a new element in /app/categories. as a result, all of the selects in the application would then have the extra item automagically.
In Polymer, I learned how to bind a property in the current element to a property in a contained element. I understand how this happens with the right events being fired etc. So, the idea would be to create a select where the items are generated by a dom-repeat, which would be bound to... a somehow global variable (?).
But... is it even possible to bind the property of a contained element to a "global" variable, rather than a property of the containing element?
OR, more broadly, is there a pattern (or even an established pattern) to make sure that when a global variable is changed (thanks to a comet message, or whatever), a bunch of elements binding to it will be notified and therefore changed (in this case, the "select" using dom-repeat to show the items!)
Here is a JSBin that shows how to create a menu via iron-ajax At this point what's missing to the JSBin is the simulation of a server push about a data change, as well as a way to have all of the menus update at the same time.
IMHO the most sane and maintainable pattern is a one way data flow approach (something along the lines of Flux or Redux (which is a bit simpler).
There is one global state object that exists as as a graph structure and the data flows down your component tree (starting with the root component).
Each component has well defined input properties and receives data from the parent component (using data-binding) and passes on parts of the data to its children. When a component changes state, it fires an event which bubbles up the component tree up to your root component that can then update your global state object (which again flows down your component tree), communicate with the backend, etc.
I can also recommend this video from the Polymer 2015 summit, which explains a similar approach (mediator pattern).
Related
I'm using Angular 1. I have a todo list application with a smart (container) component doing server-side interaction, and a dumb/pure/stateless presentation component that displays a list of todos and a text field to create a new one. The presentation component has has an onCreate event binding, so the parent component can POST a Todo to the server whenever it's created.
<todo-container>
<todo-list todos="vm.todos" on-create="vm.postTodoToServer($event)"> </todo-list>
</todo-container>
Each Todo in the <todo-list> presentation component should also have an ID so PUT/PATCH/DELETE operations can be performed (we will implement onUpdate and onDelete bindings for <todo-list> in the future. However, for newly added Todos, I won't know that ID until the Todo is POSTed to the server. Thus, <todo-container> has to give <todo-list> the ID of a newly created Todo when the server finally responds.
How do I handle this use case in an elegant way without tightly coupling the two components? I may want to use <todo-list> inside a different container elsewhere in the app (maybe without server-side interaction).
One option is to use a UUID generator from a utilities library as a temporary id when the data only exists on the client side. You can also make the id negative, so that your server process knows that, when the to-do item is posted, it doesn't actually exist on the server yet, so a real id needs to be assigned to it in keeping with the server id pattern. Then just overwrite the to-do list item with the real, server assigned data returned by the POST call.
Lodash (a utility library), for example, has a unique id generator function.
I'm implementing a JavaScript-based Vaadin component that will need to show and update a relatively large data set. I'm doing this by extending AbstractJavaScriptComponent.
I'm trying to keep the JS side as "dumb" as possible, delegating user interactions to the server using RPC, and which updates the shared state. Then the JS connector wrapper's onStateChange function is called with the new state, which causes the DOM to be updated accordingly.
I have 2 problems:
I don't want to transfer the whole data set each time a small part gets updated.
I don't want to entirely rebuild the UI each time either.
I can solve the second problem by keeping the previous state and comparing parts of it to find out what changed and only make the necessary DOM changes.
But that still leaves the first problem.
Do I have to stop using Vaadin's shared state mechanism and instead only use RPC for communicating the changes to the state?
Update:
I've been doing some testing, and it certainly appears that Vaadin's shared state mechanism is horrible in terms of efficiency:
Whenever the component calls getState() in order to update some property in the state object (or even without updating anything), the whole state object is transferred. The only way to avoid this, as far as I can see, is to not use the shared state mechanism and instead use RPC calls to communicate specific state changes to client.
There are some issues with the RPC approach that will need to be resolved, for example: if you change a value multiple times within a single request/response cycle, you don't want to make the RPC call multiple times. Instead, you want only the last value to be sent just like the shared state mechanism only sends the final state in the response. You can keep dirty flags for each part of the state that you want to send separately (or just keep a copy of the previous state and compare), but then you need to somehow trigger the RPC call at the end of the request handling. How can this be done?
Any ideas on this are welcome!
Update 2:
Vaadin 8 fixes the root issue: it sends only the changed state properties. Also, it doesn't call onStateChange() on the JS connector anymore when only doing an RPC call (and not changing any state).
OP is correct in stating that shared state synchronisation is inefficient for AbstractJavaScriptComponent-based components. The entire state object is serialised and made available to the Javascript connector's onStateChange method whenever the connector is marked as dirty. Other non-javascript components handle state updates more intelligently by only sending changes. The exact place in the code where this happens is line 97 in com.vaadin.server.LegacyCommunicationManager.java
boolean supportsDiffState = !JavaScriptConnectorState.class
.isAssignableFrom(stateType);
I'm not sure why state update is handled differently for AbstractJavaScriptComponent-based components. Maybe it's to simplify the javascript connector and remove the need to assemble a complete state object from deltas. It would be great if this could be addressed in a future version.
As you suggest, you could dispense with JavaScriptComponentState completely and rely on server->client RPC for updates. Keep dirty flags in you server-side component or compare old state and new state by any mechanism you want.
To coalesce the changes and send only one RPC call for each change, you could override beforeClientResponse(boolean initial) in your server-side component. This is called just before sending a response to the client and is your chance to add a set of RPC calls to update the client-side component.
Alternatively, you could override encodeState where you have free-reign to send exactly whatever JSON you like to the client. You could choose to add a list of changes to the base JSON object returned by super.encodeSate. Your javascript connector could interpret as appropriate in its onStateChange method.
Edited to add: calling getState() in your server-side component will mark the connector as dirty. If you want to get state without marking it as dirty then use getState(false) instead.
Following our discussion about this, I've created a drop-in replacement for AbstractJavaScriptComponent that transmits state deltas and includes some extra enhancements. It's in the very early stages but should be useful.
https://github.com/emuanalytics/vaadin-enhancedjavascript
The solution is deceptively simple: basically re-enabling state difference calculation by bypassing this line of code in com.vaadin.server.LegacyCommunicationManager.java:
boolean supportsDiffState = !JavaScriptConnectorState.class
.isAssignableFrom(stateType);
The implementation of the solution is complicated by the fact that the Vaadin classes are not easily extended so I've had to copy and re-implement 6 classes.
Vaadin's shared state works exactly like you want out of the box: when a component is added to the DOM first time, the whole shared state is transferred from server to client, so that it's possible to display the component. After that, only changes are transferred. For example, one changes the caption of a visible component by calling component.setCaption("new caption"), Vaadin only transfers that new caption text to client and "merges" that to the client-side shared state instance of the component.
Struggling to find or come up with an elegant answer to this one:
If I have multiple dynamic react components that are listening to one flux store to update their child components is it possible to emit changes to specific components rather than emitting changes to all the components that are registered to listen to changes on that store?
E.G: A dynamic component has a button and when clicked its tells the flux store to send some data to API. The dynamic component will it update its child view depending on the response and change emitted by the flux store. But since all the dynamic components are listening to the store they will all update their child views which is the undesired behaviour. Ideally the flux store could identify which component to emit the change to, or the components can identify that change is not for them.
Is this possible? Or does it go against flux principles?
I don't know if it violate flux architecture, but it seems not leveraging some beauties of it.
The beauty of a simple emit change (without change detail) is that a store wouldn't need to have explicit knowledge on views, also, with the React Virtual Dom framework, it shouldn't cost too much performance hit.
To further optimize the performance, you can implement shouldComponentUpdate on your React view (base on the differences in it's own properties), to avoid triggering the tree-diff algorithm.
See this: https://facebook.github.io/react/docs/component-specs.html
== Add more info ==
In more traditional MVC, the model will emit changes to a particular source and with particular details, e.g.
this.emit({
details: { x: 'x', y: 'y' },
source: objectA
)};
The view (or controller) that receive this needs such detail to update it's Dom, you will call the update(changes.details) instead of the initial render() method because Dom manipulation is expensive.
ReactJS 'solved' this by having another virtual Dom layer, which use pure Javascript to compute the 'optimal' differences in Dom manipulation, so in React, you never have a method call update(), you will always call render() base on current state of the view, and React does the optimization for you.
So using Flux with React, your store can just emit change without any details and the views that listen to it can just render with 'optimal' Dom manipulation (so if it's state hasn't been changed, there will be no Dom manipulation).
But of course, you will say in this case React will still trigger the virtual Dom diff computation, which still cost something. So to further optimize it, you can implement shouldComponentUpdate on a view that contains big sub-tree (base on it's own state), to avoid React to run the diff computation.
The beauty of emit a simple change, besides easier code, is that Store can be pretty much decoupled from view.
For example if you trigger specific change details for particular views, then you will need to remove or change code in store(s) when the view is not listening the that store anymore.
It does not go against flux principle but beware not having only one big store, sometime it's better to split in several tiny store.
But I think I understand your use case, one store containing a collection of similar objects (like a backbone collection).
So lets say your store receive a new object or an array of new object (or things to update in your store), you have a register function which will add this object (or update) to your store.
For sure this object has an id field (or something similar). Then for each new object of your array you just received you'll emit the id.
And your view are binded to their id as change event. Basically you use your store like an array, when the array is change you emit the key as event. Your view listen to this key/id and then get the specific data from your store still using this id/key.
Hope it's clear, let me know.
I have an array of Device objects which is fetched regularly from a REST server using $resource. Whenever this happens, the UI gets "reloaded", meaning the ng-repeat for this device array is executed again. The DOM update is annoying, because it screws up the current user interaction with devices. Instead I want the newly fetched Device array to update the existing one only WHERE stuff has changed. So if I get a fresh Device array, and there was only a name change in one of the 10 devices, then only that single data binding for that name of this one device shall incur a DOM update.
I couldn't find a method of doing this. Since it seems a common problem to me, I wanted to ask before writing my own "mergeUpdate" method which basically just does a deep-compare-replace operation and only write the things into the existing binding that actually have changed on the server-side.
Note that each device is uniquely identified by an id, thus this algorithm is possible at all. Without this id field it would not work (probably the reason why there is no generic method supplied with AngularJS).
Actually, angular.equals is a partial solution. Now I want something that can at least transfer modified properties too, without invalidating the whole array.
Thanks!
What you are looking for is "track by" for ngrepeat. In your case,
<div ng-repeat="item in items track by item.id"></div>
With this, ngrepeat will keep track of existing items and not rerender them. The merge logic is internal to ngrepeat.
One feature of my Backbone app involves associating models of type A with models of type B, which is done by dragging view A onto view B. In B's view class I listen for the drop event and from this I get the DOM element of view A, but no information about model A.
What's the best way to go about retrieving this information? My best guesses so far are
have model A save a reference to itself in the app's namespace, removing this reference on drag end if the drop handler hasn't already done so
fire an event on view A, passing a reference to model B along with the event, and then having model A call a method of model B...
store model A as a $.data attribute of view A
but all these approaches seem convoluted/inelegant.
Storing as a data-attribute is actually quite clean, and the performance will not be bad. You can store the model's cid attribute as data-cid on the DOM el, and use the collection's getByCid method to retrieve the model.
I think the cleanest way to go about it is as kinakuta mentioned in a comment to associate a dom element with the model using the id in e.g. a data-attribute.
This makes sense from an implementation point of view because it allows you to have a bidirectional dependency and you can reference one from the other easily later on when your application beccomes more complex.
Your mentioned solutions would work as well, however, I feel Solution A seems a little hackish, Solution B is less clean code wise and Solution C is essentially the same as using a data-attribute.