Rendering interface for Component libraries and shared logic in Dart web rendering frameworks #164
juancastillo0
started this conversation in
General
Replies: 1 comment
-
Seeing the Dart web frameworks share ideas / work together is what I would love to see! I get there can (and will) be disagreements on what approach should be taken when implementing solutions but even engaging in discussions / feedback will help the ecosystem. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
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 typedynamic
, 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, theBoostrapRenderer
in the repo could use extensions to implement the components and theBoostrapRenderer
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.
Related to erlage/rad#21 in the rad package github repo. The content of the issue is the same.
Thanks for reading!
Beta Was this translation helpful? Give feedback.
All reactions