implementation

[yoshuawuyts]

Implementing this should be fairly straight forward; most could be copied from https://github.com/yoshuawuyts/playground-stateful-choo/blob/master/index.js

If someone wants to implement this comment below; will guide and assist along the way where needed. If nobody steps up I'll build it out sometime this week. Cheers! ✨

[jakeburden]

🙋 I would love to look into this tonight (EST) (and maybe come back with questions)

[yoshuawuyts]

@jekrb sweet! 🎉 - don't be shy in asking questions; I'm here to help 😁

[yoshuawuyts]

@jekrb checking up how things are going, got any questions about anything?

[jakeburden]

@yoshuawuts I'm sorry I actually didn't get to this as I wanted to last night :( I underestimated how much I had on my plate at the time. If you don't mind I would still like to give this ago tonight

[yoshuawuyts]

cool, take your time! Just wanted to make sure you weren't stuck haha - I'm around tonight so post away with whatever questions you got C:

[kristoferjoseph]

@yoshuawuyts can you add some comments and links regarding the use of the placeholder template node in the playground code please? Thank you kindly.

[yoshuawuyts]

@kristoferjoseph done https://github.com/yoshuawuyts/playground-stateful-choo

[kristoferjoseph]

👌 sweet thank you!
Was thinking that in order to implement this in a generic way a user would need to pass in either a node or a template literal. Only issue then is how to hook into the onload and onunload events in a way that allows the user to define them as well.

Made a gist here that I was planning on iterating on as I have ideas

[jakeburden]

👋 hey @yoshuawuyts I've began working on the cacheElement portion of the module: https://github.com/jekrb/cache-element/blob/master/index.js Is this sort of what you were imagining it would be like?

Also do you a have a preferred method of testing that the element is indubitably returned from a cache? I imagine thats why you've included the assert module.

[yoshuawuyts]

@jekrb awesome! Yeah that seems to go in the general right direction; nice work ✨ Could you perhaps open a PR so I can comment on specific lines with some remarks? Thanks heaps!

[yoshuawuyts]

@kristoferjoseph I think the onload / onunload nodes (I'll refer to these as "stateful nodes") and "regular nodes" (non-stateful) are inherently different and thus require to be handled differently.

The way I view stateful nodes is to provide a stable environment for another library to nest in. E.g. a library like D3 requires an escape hatch from DOM diffing tree because it manages all the updates to the DOM itself. All it needs is new state to be passed in when it changes, and a notification when it's loaded and unloaded. Adding caching on top is just nice for the diffing algorithm, but not exactly necessary.

In comparison, regular nodes never need to deal with any of this state management, and thus only have to worry about caching to improve perf. Something else you might want to consider is that adding MutationObservers through the onload property is not cheap, so in case you were planning to use them a lot I'd urge you to be careful.

That is why for this library we've chosen a dual API: one for stateful nodes and one for regular nodes. I hope this makes sense; cheers!

[yoshuawuyts]

implemented, so closing now ✨