@jdubray the problem I see is that, if I have a function myAction
, and I want it to be bound to the onclick
, I have to write (as a string) something like onclick="myAction"
. But that will only work if that function is reachable from the global scope, which is something you want to avoid at all costs when developing serious JS applications.
If I pack my whole application within an object that acts as a namespace, for instance MYAPP
, and I expose my function there, I could write onclick="MYAPP.myAction"
, but still it would be better not to do so, and somehow bind the handler in another way.
nap()
doesn't know if it already has set a timer or not, it may set multiple timers i.e. running any other action during the countdown sets another timer. The end result is the same as these multiple timers don't interfere with one another, still, this could become a problem scaling. I don't like having to store a flag (mutate the state) just to indicate that a timer has been set. Do you know of any other solution?
<button id="send">
) and then attach all event handlers after view rendering (e.g. document.getElementById('send')
). Remember to have unique IDs.
createElement
, and then with the DOM Node you just have to set onClick
or append an event listener. The idea of the IDs is not very practical in my opinion... somehow you have to keep track of the IDs and then attach the handlers. Looks like more work and not so clean information workflow (normally you would like to append the handlers when creating the code for the view). I have found the minimalistic library hyperscript
quite nice, and the virtual-bom
library is based upon this, which makes easier moving from raw re-rendering to a virtual dom approach.
<input id="username" type="text" value="username">
<input id="password" type="password" value="password">
<button class="button" id="login">Login</button>
$('#login').click(function() {
var view = document.getElementById("view") ;
var session = $.post( "https://www.nomvc.com/actions/v1/logmein", { username: $( "#username" ).val(), password:$( "#password" ).val() } ) ;
session
.done(function( model ) {
view.innerHTML = state.render(model) ;})
.fail( function(data) {
view.innerHTML = state.render({error: "server error"}) ; })
}) ;
innerHTML
and then once rendered, you iterate again through the model so that you know some IDs, fetch DOM elements by ID, and then append handlers. I really would not do that. It looks way easier just to generate the DOM nodes with createElement
calls, bind the events, and return the DOM object instead of a string. Anyway, as you have commented, this is not an architecture issue...