Is this the new liquid?

[michael4reynolds]

Hi, I just requested some unit test samples for liquid when I noticed this shortly after. Is this project an evolution of liquid? If so can you put some unit tests here as well. Thanks. I'm currently using your packages instead of React. Thanks for all of them!

[localvoid]

Yes, liquid is now deprecated. This library have significantly smaller codebase and it is much easier to understand. No more magic like @property(), data(props in React terms) is just passed as any object and operator== is used to check if it is changed.

There also no things like shouldComponentUpdate, because updating is now looks like this:

Component.invalidate()

1. Component is marked as dirty
2. Added to scheduler.nextFrame.write(Component.depth) queue
3. On next frame Component.update() is invoked
4. update() is just if (updateState()) updateView();
5. updateState() is used to perform any internal updates and at the same time it should return true/false value, that indicates that the state is changed and view should be updated. In my opinion it is way much better than shouldComponentUpdate, especially when you try to implement expensive incremental updates.
6. updateView() is just root = build(), it builds new virtual dom tree and updates the old one.

parent updates its children:

1. When old.data != new.data, new.data is assigned to Component.data and component is invalidated.
2. Component.update() is invoked immediately, because it is already executed by Scheduler in writeDOM phase.
3. steps 4-6.

It is also way much faster than liquid :)

\ UPDATE 2015.04.02 **

update algorithm is now even simpler.

Component.invalidate()

...

6. updateView() should be overriden by each component.

parent updates its children:

component.data = data; // by default component.data setter uses operator== to check if data is changed
component.children = children;
component.update();

[localvoid]

There should be a better way to test, but right now this is the easiest way to test.

It didn't worked in liquid, because in liquid injectComponent injects component on the next frame.

[Janamou]

Is it in "stable" state? I have my project written in liquid and it works fine. Should I wait or rewrite it from liquid to uix? Thanks!

[localvoid]

@Janamou I am not sure, I don't use it in any project right now, tomorrow I'll start writing real application using this library :)

Build step probably will be removed in the future when Metaclasses will be implemented in Dart.

[Janamou]

So I will wait some time :-) Thanks for info!

[Scorpiion]

Hi @localvoid, first off, impressive work with both liquid and uix.

I saw that you had added a deprecated notice in the README of liquid. It would be nice if you could push a new version with that to pub just so that the deprecated notice show up there as well.

https://github.com/localvoid/liquid/blob/master/README.md https://pub.dartlang.org/packages/liquid

[localvoid]

@Scorpiion Thanks, done.

[Scorpiion]

:+1:

[sethladd]

Please make a comment on the Meta Classes PR, so they know you would be a happy user of that feature: https://github.com/gbracha/metaclasses/issues (especially include your use case and how you'd use it)

[localvoid]

@sethladd I am not sure what to write in their issues list, except that I'll be a happy user of that feature :) I have a simple use case type.new() that is covered by this proposal.

[sethladd]

@localvoid add an issue that outlines your use case. I'm sure the author would love to know how you intend to use the feature, or better yet, what you are trying to do.