DEV Community

artydev
artydev

Posted on

VanJS and a spice of DML, my Holy Graal Quest is finished...

For many years, I have been in a search of a micro frontend UI library which would fill my needs, I can assure you that I have tried many of them...

DML was quite there, but I missed reactivity, so I created MVU which was based on DML an Morphdom.

Finally arrived the little gem VanJS and spiced by DML concepts, my Graal was finally there, a big thank to Tao and Eckehard.

I can finally dedicated my time to create and no to search anymore...

And, let us see for the last time, the famous Counter with VanJS spiced by DML.

Oh, did I said that all is under 2k JS !!!

Demo

import van from "./van.js"

const {div, h1, button } = van.tags;
const {begin, end, state} = van;

const bdiv = () => begin(div());

function Counter (start = 0) {
  const counter = state(start);
  let view = bdiv();
    h1("Counter ", counter)
    button("INC").onclick = () => ++counter.val;
  end()
  return view
}

const style_app = `
  border:1px solid black;
  padding: 10px;
  background:orange`

begin(document.body)
  let app = bdiv ()
    h1({style:"text-align:center"}, "Demo VanJS / DML")
    Counter(0)
    Counter(4)
    Counter(56)
  end()
  h1("Here is an orphan counter")
  Counter(12)
  app.style = style_app;
end()
Enter fullscreen mode Exit fullscreen mode

Top comments (6)

Collapse
 
efpage profile image
Eckehard • Edited

Thank you for adopting my extensions to VanJS. Nice to see that you used the same shortcuts (like bdiv()) I will introduce in my next version of DML. Seems this is a natural way to do this :-). It is truely much better readable this way and it does not limit you in any way to do it differently.

About the state concept of VanJS

This plays really nicely and I love the way, state changes have been introduced.

I would be curious to see, how this serves on a large scale application. State changes are directly propagated to the bound objects, which possibly might cause problems like:

  • too many state updates at a time
  • circular dependency that can cause endless loops

See an example here. This creates100 buttons that update in sync. If you change to 1000, the app slows down and does not show correct time.

So, possibly we would need some further development on this point.

Possible enhancements could be:

  • programmatically inhibit all/some state updates for some time
  • synchronized release of state updates for a better user experience
  • limit the number of state changes per second
Collapse
 
artydev profile image
artydev

Hy Eckehard,

You made a great job

Concerning the state magement, obviously your are right.
But, I am afraid all this optimisations will come at some costs in term of size

We must keep in mind that VanJS is not a competitor of SolidJS or React.
neverlsess, you can always propose the idea, who knows...

Regards

Collapse
 
efpage profile image
Eckehard

Here is another demo that shows the issue.

Collapse
 
efpage profile image
Eckehard

State management is hard to control, if you rely heavily on an event based approach. If every action causes a chain-reaction, this can completely ruin the user experience.

Maybe this could be solved by adding an event function, that let´s you extend the functionallity without blowing up the code. something like

let count = van.state(default: any, onStateChanged(event): boolean)

The callback could return a false to block the event propagation. This would give you full access to the state management with just some bytes of code. I will check out if there is a nicely working option that let´s you easily trigger all events that have been blocked after you release it.

Collapse
 
tao_xin_23db52b1401921dcb profile image
Tao Xin (vanjs.org)

I guess for the line:

button("INC").onclick = () => ++counter.val + start;
Enter fullscreen mode Exit fullscreen mode

The + start part is unnecessary?

Collapse
 
artydev profile image
artydev

Thank you Tao :-)
Corrected