@Bobris yes, now I just need to write it :) My constraints are a little unique since I need to share the types of the client and the server in one place, then implement the virtual dom stuff on the client project (then compile it with ghcjs), and share the controllers / routes with the server code (compile it w/ ghc). So I can't (as of right now) store references to javascript objects in the virtual dom since the server code wouldn't know what to do with them.
@Bobris sorry for all the questions :), but I was also curious, react says it turned an O(n^3) algorithm into a O(n) algorithm using "heuristics", can you speak to what heuristics they are using? It seems that if the only diffs you're detecting are styles, classes, and attribute changes you can apply the changes in constant time. At what point does the diff algorithm spiral into O(n^3) ? And what assumptions does bobril make to keep this from happening?
heuristics are "key" fields which helps to match children order. You as developer has to provide this heuristic.
@bobris, yes the goal is to have some identical code. To share controllers, routes, types. The models will need to be different, so the plan is to use an interface (typeclass in haskell). And implement it differently on server vs. client. So
model . getPerson on the client issues ajax to the server, and on the server does a db lookup.
I want the virtual dom on the server to generate HTML to send to client, and on the client it should do a diff. I'm trying to model this based off of elm
@Bobris, react says "heuristics" it just means they don't try to diff structures that are too different. They'll just recreate from scratch. Kind of cheating :) They make it sound all scientific
@gaydenko See example http://bobris.github.io/Bobril/router2/index.html#/planets - planets are animated exactly using "async" fade out, althrough it is done from client code - this is not needed to have it core
Client code for this animation is generic it does not know what "router" wants to show next and it remebers old virtual dom so it can display both versions old and new together
@Bobris , hi! An animation is just an example. There can be other operations on node removing (AJAX call, some asynchronous cleanup using external API based on promises, and so on). Imagine fading out with random period and a condition the next planet can be shown only when the previous one is completed (that is removed from the real DOM).
@gaydenko I mean by it, that after deep thinking about async clean up, it must be solved by client code in model (Flux). It is impossible to reasonably solve it VirtualDom itself. One of problems in really simple case is order of children. Say you have one child you don't want to show it, but it has async destroy so it stay in DOM. Then you add new child, and question is should it shown before or after that async destroying node, there is no way how to define it for parent because it does not know about async destroying node.
Animation was really just sample, its completely in Javascript in client code, you can do there what ever you need. Even use promises, or support resurrection (like my animation sample).
I could be probably somehow implemented but again IMHO this is better to solve by your code in specific case...
what happens is the component gets destroyed without context
if I remove the whole view it works perfectly, but updates make errors
can you please check, why updating the dom would give a different result
because now I added keys to all internal components and the error persists
what is interesting is that when existing components, the ones which are replaced are destroyed without supplied context and node
I mean destroy function is called without context and node
but one more question
if the view is invalidated
what happens with components
do they get destroyed and new ones initialized or not?
@ekkl: It is probably you how asked on Stack Overflow. Sorry I don't have enough reputation to answer you. Hopefully it will be enough here :-). Parent is totally optional and if useful for remembering logical component tree hierarchy. addRoot is usually used for "modal" dialogs, or tooltips and similiar. So by providing parent to addRoot, in getRoots you can find out who created every new root. So for example you can animate it together with logical parent.
Also it is perfectly ok to ask by creating GitHub issue.
I have question about bobril-build. If I have sample app like here https://github.com/Bobris/bobril-build/tree/master/examples/simpleApp and I want to add another System.import()
with css path, what is the best way to do it?
or is there any other way how to add css to generated index.html?