Proposal: ESX as core JS feature

💡 Ideas
78

actually I just hit a wall and yes, that was a smart move to me, or better, it worked.

Following this discussion, I did refactor both the babel transformer and started rewriting udomsay with compatibility with both the transformer and the template literal based solution.

I guess we've all been too clever in deciding that a template must, or should, be already a unique reference, but now I'd like to present the mighty Array case:

<div>{[1, 2, 3].map(num => <span>{num}</span>)}</div>

Here my current findings after investigating why I would have all items with num equal to 3:

  • if the template for <span>{num}</span> is unique, so is its tree of tokens, where the interpolation value would always point at the latest num in the loop ... as that map happens before the outer div can do anything to understand what's its content, we're doomed
  • if the template is unique, even if its properties are updated, when the mapping reaches that interpolation starting from the outer, unique, template, it will always find the latest value set to such interpolation, even if the interpolation is not always the same (babel transformer VS template literal solution)
  • if the mapping happens instead over an always different tree of tokens, it needs the outer id to both do the mapping once, but as the tree of tokens will be always different, the found value would be always the expected one ... this was the first implementation of ESX and that's why writing a library based on it, and a transformer made sense, so I could prove the logic was working as meant.

Now, after so many hints on how to make it better without having any playground to demonstrate these hints were actually improving the situation, I find myself with two broken proposals published as npm module.

As result, I am now back to the white board trying to figure out how to solve this nested Array issue, but in short, the initial proposal was already working and delivering real-world use cases and results.

If anyone has any idea how to solve this, I am listening, but to me it seems like separating the id to retrieve mapping for that specific tree of tokens is the only way forward. It's not the best GC or heap friendly way forward, but likely the only one that works, if ergonomics of the template literal solution, or transformer, would like to be at pair of JSX.

And then again ... I feel like we over-engineered a pattern that, via JSX, has been working for nearly 10 years, so maybe it's just OK to implement ESX with that somehow disturbing, but working, outer unique identifier, creating new tokens tree per each invoke, as opposite of being smart updating the previous/latest known template.