This can be solved later, but is a lot harder when you have an entire application that needs to bee kept working, and almost trivial if you started with some reactivity built in.
This can be solved later, but is a lot harder when you have an entire application that needs to bee kept working, and almost trivial if you started with some reactivity built in.
In that case, the backend will likely have a class instancr representing it, with the first field being a discriminator on the class and the remaining fields being the details. And regardless of what the frontend does, the backend will revalidate always because you can never trust data sent from a frontend.
All that to say, maybe the form could be server side rendered, with an adaptor to convert a class definition into an html form fragment, and either embedding the js "rules" into the html itself, or making it a web component for containered usage.
Doing it this way is a big deviation from the current status quo, but I've found it to work very well and cut out a whole range of bugs. Plus it makes me think about what is truly client side state (no chance of staleness) vs server state cached in client to avoid repeat server calls (could be stale, leads to bugs).
React was invented because jQuery style state management collapsed into unmanageable code past a certain size
function initWidget(root){
// Or a bunch of calls to document.createElement, whatever you want.
const inp = root.querySelector('.input');
const check = root.querySelector('.check');
function update(){
inp.style.display = check.checked ? 'none' : 'block';
}
check.onchange = update;
}
> O, but not when this checked, etc. function initWidget(root){
// Or a bunch of calls to document.createElement, whatever you want.
const inp = root.querySelector('.input');
const check = root.querySelector('.check');
const check2 = root.querySelector('.check2');
function update(){
inp.style.display = check.checked && !check2.checked ? 'none' : 'block';
}
check.onchange = update;
check2.onchange = update;
}
Compare to React: function Widget(){
const [check1, setCheck1] = useState(false);
const [check2, setCheck2] = useState(false);
return <>
<input type="checkbox"
checked={check1} onChange={e => setCheck1(e.target.checked)}/>
<input type="checkbox"
checked={check2} onChange={e => setCheck2(e.target.checked)}/>
{check1 && !check2 && <input type="text" />}
</>;
}
Compare to Svelte: <script>
let check1 = $state(false);
let check2 = $state(false);
</script>
<input type="checkbox" bind:checked={check1}>
<input type="checkbox" bind:checked={check2}>
{#if check1 && !check2}
<input type="text">
{/if}
IME almost none of the complexity in any of the web applications I've worked with has been mitigated by the front-end framework in use. You still need to write the code to do the thing, whatever that thing is. You might as well write it in the framework that gives you the smallest bundle size and the best possible backwards compatibility, and that's vanilla JS + the standard web APIs.You don't need to remember how to properly line up useState/useEffect/useCallback and all.
You could just insert any simple state object and be ok with it, or insert a well-known state management library and it still works the same way.
For UI libraries they almost always have a vanilla option, and even better, if you are not working with google sheet level of stuff, vanilla element management is much much easier to work with.
And no need to talk about the style frameworks, they always work the vanilla way.
With some default vite configuration, nothing you need to worry anymore and the framework level stuff are simple and easy to understand and is totally manageable.