Backend Abstraction

[lights0123]

Fixes #66. I'm leaving for a week in 2 days, but I just spent an hour or two working on this today, and I'll probably do a little more tomorrow. Feel free to build on this or just do something else completely.

This introduces a new trait, GenericNode. Right now, it only has one implementation, which is a real DOM node. I'm writing this in a way so that users will have to make their components generic, but will hopefully never have to specify what that generic type is because it'll be inferred from calling render().

Right now, I have the following questions I'll need to answer to go further:

• Handling next_sibling and parent_node functions. When those just call JS functions, it's no problem because it has a full GC that can handle cyclic references. Although that's possible in Rust with some work, it would be more efficient if we could remove calls to those functions. I could also make those return an error server-side (they're only used for modifying the state), but it would make modifying the data impossible server-side—meaning you can't have some async computation render stuff later, or if you did, it'd have to be implemented differently.
• NodeRef: How to do this in a user-friendly way: do we force the user to downcast to a concrete type? It would be nice to not hardcode it being a web_sys::Node, for use cases like React Native. However, there is probably no need for it to work on the server.

[lights0123]

The basic Hello World demo compiles and works now.

Handling next_sibling and parent_node functions. When those just call JS functions, it's no problem because it has a full GC that can handle cyclic references. Although that's possible in Rust with some work, it would be more efficient if we could remove calls to those functions. I could also make those return an error server-side (they're only used for modifying the state), but it would make modifying the data impossible server-side—meaning you can't have some async computation render stuff later, or if you did, it'd have to be implemented differently.

I decided just to implement them for now. I'll probably make them error out on the server-side.

[lights0123]

Hello World, Counter, Components, and the docs all work now. Todomvc doesn't, but that's only because it uses NodeRef. Tomorrow, I'll figure out what to do about that.

[lights0123]

Although, before I do that, does this look good? The alternative way would be with feature flags. That may make NodeRef usage cleaner, but would be less flexible—if, for whatever reason, you'd like the client to be able to render both to the DOM and a string, you'd be prevented from doing so.

Actually, I think I came up with a solution: make NodeRef's get and other functions have a generic parameter which is DOMNode by default. The user can override it if desired for use with an alternate renderer.

[lukechu10]

Looks good. I think it would make more sense with feature flags because everything that is wasm-bindgen or web-sys would need to be put behind a conditional compilation flag anyways. Otherwise it won't compile on non wasm32 targets.
It would also be nice if we didn't have to make everything generic over G as that is a bit verbose.

The way you implemented this wasn't exactly the way I thought of doing it but that's OK. I was thinking more along the lines of GenericNode having a .to_node() method which would generate DomNodes from the GenericNode. What do you think?

[lukechu10]

Sorry I missed some of the new changes in my previous review

[lights0123]

everything that is wasm-bindgen or web-sys would need to be put behind a conditional compilation flag anyways. Otherwise it won't compile on non wasm32 targets.

That's not true—it just panics at runtime.

[lukechu10]

That's not true—it just panics at runtime.

Yup you're right. My bad. Although I still don't like the generic type params on all the components. Maybe something could be done using dynamic dispatch?

Edit Forget when I said about dynamic dispatch. It doesn't make any sense. I just had an idea. How about making G have a default type of DomNode when a web feature is enabled or SsrNode when a ssr feature is enabled. When both features are enabled, we could either default it to DomNode or not provide a default. What do you think?

[lukechu10]

Just looked at the ssr example you added and it really is quite impressive! Thanks a lot for all the work so far.

[lukechu10]

About feature flags, it might be a good idea to add a ssr feature anyways to prevent penalizing users who don't use SSR with worse compile times.

[lukechu10]

I'll fix the integration tests and I'll probably merge this. Thanks for all the work @lights0123!