Refactor dependency on dart:html

[jonahwilliams]

We need to remove the direct dependency on dart:html for most of the classes in butterfly, in order to support running the application outside of the browser (server, tests, workers).

I'd propose creating an abstract Renderer class which could have platform dependent implementations: DomRenderer, TestRenderer, and so on.

For example, currently on the StatelessWidget render we have the following method:

RenderNode instantiate(Tree t) => new RenderStatelessWidget(t, this);

I'd propose a design something like this

R instantiate<R>(Renderer<R> renderer) => renderer.renderStatelessWidget(this);

Some open questions:

1. Should the instantiate method even return a value, or can it all be done internally in the Renderer?
2. Can the renderer handle Tree construction without the widget's knowledge?

[yjbanov]

Another possibility is an abstract diff tree, similar to what did in the barista prototype. The idea is that the environment gives the node tree an interface to sync to, and that object can have multiple implementations, similar your Renderer approach.

The difference between a Renderer and diff tree is that this approach is a little more functional-style where the diff tree itself is a value that is passed around. Then we can share implementations of Node and RenderNode classes.

Let's sync about which way to go. We should also get @matanlurey's view on this.

[matanlurey]

If this is going to be a serious (i.e. not just a toy framework) we probably want to design and start this almost over from the beginning with this in mind.

Passing a renderer around everyone isn't my idea of a great abstraction.

On Fri, Mar 24, 2017 at 2:44 PM Yegor notifications@github.com wrote:

Another possibility is an abstract diff tree, similar to what did in the barista prototype https://github.com/yjbanov/barista2/blob/c8ab726c340a519e8f7db70626fc4010e22c0edd/sync.h#L34. The idea is that the environment gives the node tree https://github.com/yjbanov/barista2/blob/c8ab726c340a519e8f7db70626fc4010e22c0edd/api.h#L63 an interface to sync to, and that object can have multiple implementations, similar your Renderer approach.

The difference between a Renderer and diff tree is that this approach is a little more functional-style where the diff tree itself is a value that is passed around. Then we can share implementations of Node and RenderNode classes.

Let's sync about which way to go. We should also get @matanlurey https://github.com/matanlurey's view on this.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/yjbanov/butterfly/issues/9#issuecomment-289150508, or mute the thread https://github.com/notifications/unsubscribe-auth/AAKQ7pSQ9HGnDuT4prrAI7FBI-16BwrFks5rpDkvgaJpZM4Moq_Q .

[jonahwilliams]

design and start this almost over from the beginning

It's treason then.

[yjbanov]

@matanlurey could you please describe the issues with a renderer? Perhaps there are ways to fix them without going back to the whiteboard.

[yjbanov]

Fixed in https://github.com/yjbanov/butterfly/commit/5afac471e74d64c17d7b5f35ff2055914a7d4df3