Rendering interface for Component libraries and shared logic in Dart web rendering frameworks

[juancastillo0]

Hi, thanks for you work!

I have been building the web bootstrap components bindings in this repo. At the moment it supports three different frameworks: deact, jaspr and rad. I have implemented bindings for each of the frameworks separately in different packages. You can view all the implemented bootstrap components in the deployed page, that page renders the components with package:deact. Another deact example is this one and a jaspr example is this one. At the moment, I have not implemented any rad examples.

Maybe it would be nice to collaborate on a shared interface between the Dart web frameworks, perhaps something similar to what bootstrap_dart is doing, but where the libraries implement them natively. You can view the Dart interface in the readme of the repo.

Perhaps a "web_rendering_interface" package that exposes interfaces like Ref, State, BuildContext, Component, some base hooks, and the ability to render HTML elements, text nodes and fragments (List of Components) could be used. The rendering packages (deact, jaspr or rad) implement these interfaces and the component packages (or logic packages such as for hooks or routing) use those interfaces.

At the moment, bootstrap_dart uses a global BoostrapRenderer instance that has to be overridden to use the renderer for each package like this example that executes this function. The returned components are of type dynamic, which works, but maybe isn't great. BoostrapRenderer has a generic type parameter for the component type which could be used to improve type safety. For type safety, the BoostrapRenderer in the repo could use extensions to implement the components and the BoostrapRenderer instance could be used directly (boostrapRenderer.card(...) to return a Card bootstrap component). The extensions would need to be imported since they contain the implementation for each component. Or perhaps we could expose a Component interface in "web_rendering_interface" so that the component libraries return an instance of that interface. Or reimplement each component in all the packages that interface the rendering framework with the component libraries, perhaps with code generation to maintain documentation and the API synched.

This would allow for the component libraries to use the same code and interface with multiple different rendering libraries. As well as perhaps share hooks between different frameworks. This could also be extended to other functionalities like server side rendering, routing or dependency injection. Where the routing logic could be used for every rendering package.

Thanks for reading!

[hamsbrar]

Considering the current state of dart web frameworks I think it'd cool to have the ability to switch underlying framework(deact, jaspr, dawn, rad etc.). Not only it'll help share component libraries and logic(as you said), it'll also help users keep their apps up and running in case the framework they're using is no longer maintained.

I see the problem with the BootstrapRenderer is the lack of types and it's obivous, we cannot program against multiple render implementations at once. We can come up with a single interface for calls being forwarded in BootstrapRenderer but I think
instead of supplying renderer(like BootstrapRenderer) a much better way would be to supply the app to a renderer. For this, we've to create a web_interface package in a way that:

1. Component libraries depends only on web_interface package.
2. Rendering framework knows how to render web_interface nodes.
3. User code depends mostly on web_interface(uses just the runApp from rendering framework of their choice).

If you/others have something else in mind, I'm open to discuss that as well.

Thanks

[juancastillo0]

Sorry for the late response.

Thanks for the comment! This is a great idea, I will try to find time to implement your idea and perhaps modify rad to use the interfaces. I think I will use bootstrap and perhaps some hooks or routing as a case study for the new package. Also if anyone else would like to try to define a set of interfaces or discuss more design ideas, that would be great!

Thanks

[hamsbrar]

Two things,

1. Hooks and routing are complex. I'd suggest to start with absolute basics (just HTML nodes and probably a state node).

2. Before we start out on anything, what about other authors?

   • Dawn looks unstable but active.
   • Deact is a internal/personal project.
   • DawUI is still in its infancy.
   • Jaspr is currently experimental.

   I'm not sure whether other authors are interested in creating a common web_interface as most of these frameworks are either experimental or being developed at a very slow pace. I mean it'd be pointless to try to design and define interfaces if Rad is the only framework that's going to support such an interface.

[juancastillo0]

Yeah, I agree that it is still early for some, but I think (or hope) that people will see the usefulness of sharing code. If a framework author can support bootstrap, material design components, hooks, routing and other stuff out-of-the-box by implementing a couple of interfaces, they will at least think about it. And it will also be an exploration for the future, when everything is more mature.

bootstrap_dart's interface already uses hooks for state nodes and I think some other hooks could be implemented, maybe bring some ideas from the react community or maybe with these ones that are already implemented. I agree that Routing would be harder, but maybe a simple implementation could show the usefulness, I was implementing an SPA deact router and there is also jaspr_router, maybe those could be a starting point.

[hamsbrar]

I think we(you?) should create a separate repository(web_interface) and open an issue over there to see if others are interested.

[hamsbrar]

I'm going to close this for now. I'll happily contribute & implement web_interface but as I mentioned above, this conversation has to be moved in a dedicated repository so that we can invite others and see if they're interested.

Thanks