Unused local var elem

[mindplay-dk]

I wonder what the var elem was for:

https://github.com/composor/nano-byte/blob/master/render-vdom.js#L26

It appears it's only assigned to but never used for anything?

[rbiggs]

Good catch. That's a giblet. It served a purpose before I added in the watchedNodes object to keep track of rendered nodes. After getting it to work with watchedNodes I forget about that chunk, mostly because it didn't cause any problems. That said. Nano-byte is more an experiment in minimalism. It's good for really small things, but I wouldn't use it for a large project. It mostly serve as a teaching/learning project for people interested in home libraries/frameworks that use virtual dom work. Removed now.

For real stuff I'd look at Composi on here. It's only 3KB with virtual dom and a component architecture similar to React: props, one-way data flow, etc. Main difference: Composi uses real classes that you instantiate with the new keyword. That will cause the component to render to the DOM. React sends everything into the black hole of their ReactDOM.render function. You never instantiate a class and therefore never have a reference to it. Having a real instance of a component means you can console log it and examine its properties, state and methods in real time. There's a lot I like about React, functional components, pure functions, state management, passing props down, etc. But I absolutely hate the voodoo of passing a component class to render and watching it disappear into the bowels of React.

[mindplay-dk]

I did look at Composi - and over the past few months have looked at just about anything and everything, including something I wrote myself, but don't particularly want to roll my own.

I am definitely looking for something minimalist, but I'm not big on React, or the idea of having classes/objects at all, so that's not a strong selling point for me ;-)

I'm hoping to go fully-functional, so I'm looking at the SAM pattern, and so far my favorite option for that is Picodom, which does only exactly the one thing I need: incrementally patches from JSX to DOM, with keyed updates, and create/destroy life-cycle events for integration with third-party JS. It's still young and has some problems, and I'm trying to help.

From my own personal point of view, the thing I'm trying to avoid, is managing components - so the original problem was managing DOM objects, and, in a sense, I find that React (et al) have somehow managed to recreate the original problem of managing DOM objects, by introducing some other (albeit much more powerful) component abstraction, as well as a complex facility to manage the life-cycle of those objects; and while you may be able to alleviate some of that management by exposing the objects, as you do in Composi, I feel like this is almost a full-on return to the original problem of managing objects.

What I'm hoping to do with the SAM pattern, is arrive at the view as a simple function of the state - I want to never again need an object reference of any sort, just a single function that synchronizes the view, no matter the present or updated state.

I don't think that's unrealistic or utopian at all. It's almost fully solved by simply injecting an HTML string from the view-function via .innerHTML, as covered by Jean-Jacques Dubary here - only with the obvious drawback of losing component state, as I noted in my reply here. But that's really the only problem I need/want to solve - basically everything else is good to go.

That's just my take on this anyway :-)

[rbiggs]

Never argue with someone who already knows what they want ;-) Actually, I remember when Jean-Jacques Dubary published his first couple of articles, before he had a name for the SAM pattern. I found it interesting, but it didn't address my needs for reusable components. That was the same problem I had with Elm and Hyperapp, no solution for reusable components.

The reason I was so focused on support for components was because I have a framework, ChocolateChip-U that provides widgets for building mobile web apps for Android and iOS. Not being able to find any other good support for components/widgets, I wound up creating Composi. This was a basically the Component class from ChocolateChip-UI with a virtual dom. I'm currently working on porting ChocolateChip-UI to Composi. Interestingly, in the conversion, the components are becoming functional, stateless components. So, technically they could be used with anything that can handle functional components.

Although Composi does have a Component class, you can use it with just the h and render function, reducing the result to just 1KB. In that case you would be using functional components without state. You'd need to use something for state management, Redux, Mobx or whatever. By then, though, you might as well be using Picodom.

[mindplay-dk]

Although Composi does have a Component class, you can use it with just the h and render function, reducing the result to just 1KB. In that case you would be using functional components without state.

That's what I was hoping to do - but the life-cycle abstraction is at the component-level, and this is what's different about Picodom: the life-cycle management is at the element-level, which means you can have life-cycle events without needing components as life-cycle hooks - that's why Picodom only supports functional components.

You'd need to use something for state management, Redux, Mobx or whatever. By then, though, you might as well be using Picodom.

I'm not sure what you mean? Picodom doesn't do state management either.

And with the SAM pattern, I don't need state management - just POJO :-)