It does, but emulated by default, you have to explicitly add ViewEncapsulation.NATIVE to your component decorator, or NONE if you wish/are forced to disable it.
But how do you handle the encapsulation of views? If I am working on a React app and I want to add a new interface, say a simple view that displays a record and has some controls on the left side, I might write something like this:
This view would be injected into the frame of the app that already has a navbar and footer, the layout would be pre-built via my panel components Left and Right, and if I want to change the control-panel I can go to that file and make any changes I want so long as the API stays the same. Similarly, if the schema changes and we need to update the way we display records, I would go to the RecordView component and change it because it is a decoupled module. I just don't see how you can accomplish this with vanilla HTML and JS.
It allows you to do partial updates, but indeed it doesn’t support view transitions out of the box. :/ That said, the native wrappers offer built-in transitions, and you could probably hack web transitions with some modding and a component library.
I dont think this is the type of composition I am talking about. This composes pure views, like react, but it doesn't compose their state, same as react.
Almost correct. To be precise, it doesn't have the objects in memory, it instantiates all the native components on demand based on the JSON recipe. And all of them of course go away once you close that view.
Yes. Except mobx ;)
I like to use function components together with class based observable view models. Only a single hook wires them up. Works like a charm and avoids all the IMHO confusing hook complexity.
You can still do that when you use utility classes. The benefit is that now you have a guarantee that you can drop a view anywhere in the application and have it render the same. I can restructure the HTML without worrying that I broke styling in an edge case.
Well, if you need the performance increase, the yes. Otherwise your options are to (maybe) tweak your current implementation so it continues to work or rewrite the functionality to be compatible with the view layer. This is the same trade-off you make with React since it's basically the same technology.
Looks like that's on codemirror framework? Any good resources you could share on wiring up custom language and view? I've managed to kinda get something working with lezer but the docs aren't great and I want to setup some pretty specific behaviour in the view with folding and validation etc.
It would be a great move to isolate the Views/UI part of this out from the rest of the code base, which would make it more usable inside other MV* frameworks like Angular or Ember.
I might be able to help a little with this. I have some code somewhere that keeps a stack of "views" and a view controller that pops them in and out of the DOM that can be easily animated to be native-like
Yes, I’ve done this with LiveView and Tauri and it works.
At the time, the barrier to my investigations was LiveView interop with component frameworks. Even Ionic Vue was tricky to get the re-rendering right.
Having a native framework ontop of liveview unlocks shipping it for desktop apps. Bundle a local first database and you have a highly productive stack for building snappy, small bundle, native apps with web technologies.
reply