Coding is as much a matter of personal growth as it is of logic and control-flow. I keep patience, curiosity, & exuberance in the same toolbox as vim and git.
*Opinions posted are my own*
Do you mean that lit elements isn't well suited for a webcompnent where the user enters data?
Just the opposite. Because of the one-way data flow, lit-html encourages you to explicitly and declaratively handle user input.
Polymer-Style Two-Way
<my-inputvalue="{{theValue}}"></my-input>
At any given moment, what does theValue represent? Is it the state held by the parent and passing down to the child? Is it the new input being sent up to the parent by <my-input>?
Here, the developer knows exactly what's happenning. theValue is only ever passed down to <my-input>. input events are handled by onInput (which might set the state in the parent, or in a state container, or whatever you choose)
So for your company's component library, I recommend either implementing a decorator component:
<my-input><input/></my-input>
Or implementing <input> in the root of <my-input>, and listening for the composed change event on that. Make sure to handle your state internally, e.g.
Just the opposite. Because of the one-way data flow, lit-html encourages you to explicitly and declaratively handle user input.
Polymer-Style Two-Way
At any given moment, what does
theValue
represent? Is it the state held by the parent and passing down to the child? Is it the new input being sent up to the parent by<my-input>
?One-Way Binding with lit-html
Here, the developer knows exactly what's happenning.
theValue
is only ever passed down to<my-input>
.input
events are handled byonInput
(which might set the state in the parent, or in a state container, or whatever you choose)So for your company's component library, I recommend either implementing a decorator component:
Or implementing
<input>
in the root of<my-input>
, and listening for the composedchange
event on that. Make sure to handle your state internally, e.g.