I use vanilla JS for interactive webpages, and I'm trying to understand whether my design pattern is correctly implementing the principle of reactivity.
(Note: I'm not referring to the library React -- though I'm happy for answers to draw on features or strategies of such libraries).
My basic understanding is that you have some data which acts as your single source of truth, you listen for changes, and when that data changes, your page|app|component re-renders to reflect that.
Here's a simplified version of what I do, with questions after.
Let's say I have my single source of truth:
let data = {}
data.someContent = 'Hello World'
data.color = 'red'
and my app's markup in a template string for dynamic rendering:
function template(data) {
return `
<div id="app" style="color:${data.color}">${data.someContent}</div>
`
}
// assume there are also plain HTML inputs on the page, outside of what gets re-rendered.
a function that renders based on the data:
function render(data) {
document.getElementById('app').innerHtml = template(data)
}
then, for the equivalent of reactivity from client-side updates:
document.addEventListener('input', (e) => {
data[e.target.id] = e.target.value // update data to reflect input
render(data) // re-render based on new data
})
and from server-side updates:
function fetchDataAndReRender() {
data.propToUpdate = // fetch data from server
render(data) // again, re-render
return
}
So, we've got the single source of truth and re-rendering based on data updates.
data object, e.g. via Proxies. It seems like the only advantage to that is avoiding manually calling render(). Is that correct?--
EDIT: Adding a link to a blog post that mimics the vanilla reactive strategy above: https://css-tricks.com/reactive-uis-vanillajs-part-1-pure-functional-style/ There are some minor variations, but it serves as a good reference point for anyone interested in this style.
The main thing I'm missing here is a way to optimize re-renders.
Interacting with the DOM is expensive, so apart from using a Proxy around your data/state to automatically call render, you would ideally want to avoid just replacing all the HTML for your app if only one element or, say, one attribute, has changed:
Consider updating an <input>. If you are not able to detect that only its value has changed and update that, and instead you replace the whole HTML that includes this input, the cursor will move to the end after each re-render (so probably after every character I type).
Consider a drag & drop feature. If you are not able to detect that the user is dragging something across the screen and only update the CSS transform property on it, and instead you replace the whole HTML that includes the element being dragged, the performance is going to be horrible. Also, you'll be interrupting the drag events, so this won't work at all.
Another possible optimization would be batching updates, so if you update your data 3 times in a row, you could potentially only update the HTML once with the final result. You already mentioned you debounce continuous input events, which would be one way of doing it.
Answers to your comments:
(1) I assumed you wanted a general purpose solution, that's where being able to detect changes and only update the parts of the DOM that need to be updated is a must.
If your only need to (re)render small static chunks of HTML, then you can probably go without this. The main two reasons being:
As you said, there's no interactivity, so you'll not experience the issues I exemplified.
As you updates are small, you are unlikely to see any performance issues by replacing blocks of HTML instead of trying to update the existing elements in the DOM.
(2) In any case, the main problem you would have to face if trying to update only what has change would not be finding the data that has changed (regardless of whether you use a Proxy or not), but to map that to the elements that need to be updated and actions that would perform those updates.
(3) You can also make compromises on the app side, say, that the data must be immutable (like with React).