Bloomca
commented
3 weeks ago Hi! Thanks for checking it out!
I think that adding a mapper is a very hard task, and ultimately will be both error-prone and hard to get value from. The idea of Veles is to subscribe to individual updates inside the markup using createState primitives, and React expects all data either to come from props or from hooks. So even if we somehow can parse a single component using either React.createElement or Veles.createElement, the logic inside won't really work between them.
I am developing an application to see how viable it can be for a more general application (https://github.com/Bloomca/veles-calendar-app), but I didn't get too far, so it is hard to understand yet.
The best use-case right now is probably to create a subview in Veles with lots of interactivity to gain the performance benefits. E.g. using React, one would just have a memoized component (to avoid any re-renders) which will render a Veles app and mount it to a node.
I am thinking about adding a "stable" node which will not be re-created and just reused, and this way you can use it for React Portals to have "React -> Veles -> React" tree, but I am not 100% sure it will be very valuable.
Hi, a react is not just a framework, but it is a code platform that have a many solutions for any use case.
It would be nice to have some mapper that let us to use react components with your framework. This mapper should translate react calls to Veles calls.
As result, you may propose to use Veles in production, and you could find a users who would agreed with it, because this is not too radical since it is possible to still use whole react infrastructure but with your rendering engine.
This is the only way to battle test your library on a real use cases.