I'm using Backbone.js. In my view, I have a textarea whose keyup is bound to a function like this (but see edit below):
this.model.save({text: self.$('textarea').val()}, {patch: true});
In the view's initialize function, I bind the model's change event to the view's render function:
initialize: function() {
this.listenTo(this.model, 'change', _.bind(this.render, this));
},
Trouble is, when the user types in the textarea, the following sequence of events occurs:
The keyup event fires.
The keyup handler calls save on the model.
The call to save triggers the model's model's change event.
The view, listening for the model's change event, calls render.
The textarea is replaced in the DOM.
The textarea is no longer focused, and the text cursor position is lost.
What is the best practice for situations like this, where a texarea's keyup event needs to trigger a sync? Some options I have considered:
Don't bind change to render. Disadvantage: If the model data changes due to anything other than the user typing, the textarea doesn't automatically update.
Read and remember the cursor position at the beginning of render. Set the cursor position at the end of render. Disadvantage: Depends on cursor manipulation features for which browser support is spotty.
In the keyup handler, set a temporary property on the view telling it not to re-render. Unset it after the model has been saved. Disadvantage: Feels like spaghetti code, fights against the structure of Backbone.
Are there any options I'm not seeing? Do you recommend one of the options above?
Edit:
I didn't want to distract from the main point, but since it came up in one of the answers: I'm not binding directly to keyup, but intermediating it with _.debounce. Thus, the event handler only runs once the user stops typing, as defined by a certain amount of time elapsing since the last keyup.
First of all I'd like to discourage this as it seems like really strange behaviour to save your model on keyup. If there is a use-case which really necessitates this I'd suggest using the input event at the very least - otherwise you'll end up saving the model every time the user presses even an arrow key, shift, ctrl etc.
I think you'll also want to debounce the input events by 500ms or so you're not actually saving the model every single keystroke.
To address your comment in point 1:
Disadvantage: If the model data changes due to anything other than the
user typing, the textarea doesn't automatically update
You need to ask yourself the likelihood of this happening and how important it is that the view is rerendered if this was to happen.
Finally, if you decide that this is indeed likely and it is important that the view is rerendered, then you can try something like this
http://jsfiddle.net/nuewwdmr/2/
One of the important parts here is the mapping of model attribute names to the name field of your inputs. What I've done here follows the sequence of events you described above. The difference is that when the model changes, we inspect the changed attributes and update the value of the corresponding element in the template.
This works fine in a very simple situation, the happy path, where the user is typing in a "normal" way into the input. If the user, however, decides to go back to the start of the input and change a letter to capitalize it, for example, the cursor will jump to end of the string after the change event in the model occurs.
The behaviour you require here is really two-way data-binding which is by no means trivial, especially with Backbone given just how little functionality a Backbone View has.
My advice would be your point 1
Don't bind change to render
Edit
If you want to look further into model / view binding you could take a look at two libraries:
stickit
epoxy
I've used stickit before and it's...fine. Not great. It's ok for simple bindings, for example binding a "top-level" model attribute to an input element. Once you get into nested attributes you'll run into problems and you'll then have to look into something like Backbone Deep Model.
Like I said, Backbone's View doesn't offer very much. If you've got the time I'd suggest looking into using React components in place of Backbone Views, or even look at some of the interesting stuff that ampersand have to offer.
Related
I think I found a hard requirement to change behavior in a beforeChange handler based on the bindingContext of where a change is coming from. I already made some changes where a beforeChange handler gets to see the newValue along with the oldValue and where the handler can return boolean false to prevent the change from going forward.
The reason for this is the same objects may be bound to two (or more) different html nodes. The parent node may use different observables to wrap the same model object. But at some point, the child nodes are bound to properties through the same observables, sharing the same observable in more than one view element. When a change happens, I need to know from which of the two view elements the change originated.
I can save the bindingContext where the observable was made in the closure of my callbacks. But now I need the event to tell me what the bindingContext of the element was which just initiated the value change.
I can see the binding context somewhere in this domData thing, as follows: the valueUpdateHandler is called with the event object as argument it doesn't care about. But the event.target is our element that originated the change. I can see on that event target something like: "__ko__1655641582113" which I guess I am supposed to access with this ko.util.domData.
ko.utils.domData.get(arguments[0].target, "1__ko__1655641582113")
and lo and behold here I get an object with {alreadyBound: true, context: ko.bindingContext}
So I could force my way into this secret place and then get that context
ko.utils.domData.get($0, "1__ko__1655641582113").context.$parentContext.$rawData
and from there I could tell if I am in the element that should go forward with the change or not.
I am sure if anybody read this far that you'd be puzzled asking why in the hell I want to do that. But think about it, the observables are cool and all, but you sometimes need different behaviors based on where in your app the user is. In some areas they are just supposed to view, in others they can make (controlled) updates.
In other words, I know what I want is right and just, but I am wondering why it is so hard to get to what I want. For example, why the domData property is such a cryptic thing with a (timestamp) instead of a constant predictably named property. It's as if to tell me that I am making a big mistake even going there...
I see a lot of examples using React with backbone, there is however some things that are still somewhat unclear to me. In nearly all examples they show how you can get your component to listen to a model or collection and update the view accordingly, this seems pretty straightforward, you can use the Backbone Mixin or you can setup some event listeners in "componentDidMount()".
What is unclear to me is how to handle the other way, ie when a user writes in some input field, I then want to set this same value on my model, which ultimately is what i validate and then save on the server.
With simple forms this is also pretty straightforward, you can have a callback for the onChange event, example:
return <div><input type="text" onChange={this.setPrice} /></div>
All good, in the setPrice function I can now do something like:
this.props.myModel.set('price', e.target.value);
This works, but two things that immediately strike me:
The set method will be called on the model every single key event, since Reacts "onChange" actually executes on every key event, when you type in the textbox.
My second concern is, this works good for simple forms, however we have forms that have upwards 30-40 different input fields, having an onChange event on all of these input boxes, checkboxes and what have you seems counterproductive.
Right now, we have a databinding in our Backbone Views that simply sets whatever the user types on these input fields on the model, this does not seem to be the way togo in React though since what would be updated if you use something like ReactLink is the properties inside "state" on the Component, not properties directly on the model.
Is there a best practice here, or is this "marriage" between React and Backbone simply not meant to be? It would seem as if you would need to somehow map each input field to a specific property on the model. I am not sure if this is a good thing todo with React.
Thanks
You can call the setPrice method onBlur instead of onChange so that you will update the state when the user clicks or tabs out of the field.
This is more efficient for longer forms in my opinion as you are guaranteed that the user will tab or click to the next field.
Can anyone suggest how do I create a service to over ride angular js default $watch and $digest loop?
My requirement is to $watch a scope object with a listener and the listener function should have 4 parameters, #param1 - newObject, #param2 - oldObject, #param3 - Exact attribute which changed, #param4 - the heirarchy of the attribute in that object to that attribute which changed.
required :-
$scope.$watch('objectName', function(param1,param2,param3,param4){
//log param3 and param4 in a stack for later use.
//Note:- I dont want to log entire changed object since its too big.
}, true);
NOTE:- Right now we can deep watch an object but the listener would provide us with 2 objects, old object and new object. All I want is to get the exact attribute changed.
Any help will be highly appreciated. Please refer the below link for my complete problem.
Undo Redo In Angular JS
I think you can probably create an undo system that uses some sort of classification system for various types of undo along with a more event oriented approach. I focused on comments you made about iterating whole objects for each keystroke so will start there
I'm assuming that you aren't updating server for every keystroke on inputs in which case you wouldn't need to watch anything other than the specific input's key events while it is in focus. When you bind CTRL +Z to the document, do it in a way that nothing global happens when an input is in focus.
Following scenario is based on simplest UI action to track...update field only.
On focus of an input you would immediately take a copy of it's current model value, and store that as value to use for a complete undo of the ng-model later.
While in focus, CTRL+Z would be bound to that input and keystrokes events can be undone at very local level not impacting any need to watch at higher level. Unbind key events for that input on blur.
On blur of an input, you would then be able to $emit an update event that you would track as category like "field update". Send the old stored value , the object that contains the ng-model and update category to a tracking service that listens for updates and pushes updates into an undo array.
When user now hits undo, service looks at update type and changes the value of the object associated to the field name stored and removes that last stored item from the queue
I did something similar to this using only jQuery for a UI that was set up to both create and manage a web page layout with absolute positioned elements throughout, as well as inserting and updating content.
I've only started on user level input that assumes no new data objects created or deleted. Those might be handled by $.watch watching array lengths. By only watching length you wont have to iterate over every property of every object contained to figure out what changed.
One helpful tracking property for all of this is the $$hashKey property that angular gives to every object it touches in all scopes. Using haskey could help map array length changes to find differences. I haven't though all of this section through a lot yet.
Hope the event driven input tracking concept helps. At least at user input level it would cut out a significant amount of overhead using $watch
Also angular recently added a shallower listener $watchCollection was added in 1.2. Haven't used it yet, but surely lightens overhead where it's use case might not warrant a full watch
Most Backbone tutorials and examples I've come across suggest something like this for your models:
this.model.on('change', this.render, this);
In my particular case, I'm creating a view for my model that is a form, and the fields are tied to model properties. When the user updates a field on the form, the model should also be updated. This has not been a problem, as I have events bound to the fields that fire off the appropriate code to update my model.
However, the problem I'm running across is that I also want the view to update when the model does (as in the above mentioned ubiquitous change event binding). This is causing the view to re-render itself any time a field is updated, because the underlying model is changing. So now any time I change a value on the form, my view is being redrawn. This is both inefficient, and causing lots of frustrating bugs (like focus being lost).
How is this problem normally handled?
http://backbonejs.org/#Events-catalog
When you don't want your model change to trigger your view's rendering, use {silent: true}. As of the last version of Backbone, this will completely silence the change (it was previously just shut until the next non-silent change). So when the change to your model comes from some user input, use the silent flag.
If you would like to update a model without firing a change event event you can do so by calling,
this.model.set('val', newval, {silent:true});
I'm new to Backbone.js and am having trouble figuring out the proper architecture for a model-view relationship.
I have a view that holds an input box and a model that is supposed to take the contents of that input box and send it to the server.
My issue is that I don't always have a discreet DOM event that triggers a request for the view to update the model data, such as input.change. Sometimes the code itself needs to ask the model to send updates to the server.
I've thought of three solutions to this problem so far, I'm not sure if any if them are any good though:
Update the model on the input element's keypress event
Once the view is initialized with the model, have the view update/add a function to the model called 'get_input_value()' that returns the value of the input box
Whenever the application needs to request the model to update the server, first call a function in the view that updates all of the information that the user has typed into the view to the model.
Please bear in mind that this is a simplified example. The view contains child views as well, all of which hold a number of elements that the user can manipulate, the model needs to be updated with all of this information so that it can update the server.
Any help and input is appreciated! Thanks so much!
Edit :::
Base on machineghost's response, I now see that I did not articulate this problem correctly:
There is a DOM event, but the problem is that it doesn't necessarily originate from inside the view that uses the model. It may originate from the Router or another view and be triggered by a global event handler. Additionally, there is not a 1:1 View-Model relationship. This model is used by multiple views who express the model in different ways. So in this case, it seems like the command to update the server should not go through a View, but to the model itself. If that is the case, the model must be able to say "Sync me with my views!".
But I don't know how to do this without breaking the rules and thus creating other problems with architecture...
Ok this is kind of a subjective question, so forgive me if this just seems like me spouting off my two cents. And before I even answer your question, I have to admit I'm a bit skeptical that you:
don't always have a discreet DOM event
because pretty much anything the user can do triggers an event that you can watch for. For instance, if you want to wait until a user changes a text input there's change, but also (as you noted) the various key* events, plus there's blur (which is commonly used for this sort of thing). Between the 3(+) you should always be able to respond appropriately to the user's actions. It would only be if (say) you had to save the text input's contents every 3 seconds that it would truly be independent of DOM events.
So, without knowing your particulars, I just have to point out that something smells fishy there. But anyhow, as for your actual question, here's my take on your ideas:
Update the model on the input element's keypress event
This certainly would work, but just be sure to use the view to do the actual event handling/model setting; hooking up the onKeyPress handler in the model would be a bad idea
Overall this approach seems pretty standard, and fits the Backbone paradigm.
Once the view is initialized with the model, have the view update/add a function to the model called 'get_input_value()' that returns the value of the input box
I don't quite get how this helps your problem, plus it seems to put the concerns in the wrong place: the model should (ideally) have nothing to do with the DOM.
Whenever the application needs to request the model to update the server, first call a function in the view that updates all of the information that the user has typed into the view to the model.
Is the save happening every 5 minutes or something? If not, then it's presumably happening in response to the user's actions, and you should use an event handler to respond.
However, if you truly do need to make the sync independent of user actions, I'd recommend using a custom event to manage things. In other words, in your model's sync method put something like this.trigger('preSync'). Then, every view which uses that model can bind some sort of updateMyModelValue method, ie. this.model.on('preSync', this.updateMyModelValue, this);.
This way, your model code is never directly interacting with the DOM at all; instead, it just worries about the stuff it's supposed to worry about (the data) and the views pay attention for when they need to update that data from the DOM.
Hope that helps.
* EDIT (in response to your editing of your question) *
If that is the case, the model must be able to say "Sync me with my views!".
The general Backbone way for a model to say ... well, pretty much anything to its views is through events.
(Technically you could maintain a list of a model's views in the model itself, and then iterate through that list to tell the views to do things. Backbone is even un-opinionated enough to let you do that. However, from a maintainability standpoint that seems like a terrible approach to me.)
My example of a "presync" event (above) demonstrates how you'd use this technique; comment back if any of it is unclear.
Similarly, if you have an issue of:
View A catches an event
View B needs to do something in response to that event
You basically have two options:
1) You can tightly couple the two views. Let's say have a table view that creates row views, but needs to respond to events that happen in those rows. You can pass the table itself as an option to the row when you create it (new Row({table:this})), and then when those rows need to tell their table "an event happened" they can just do this.options.table.informThatAnEventHappened(). This is a great approach if the two views are inherently related, like a table and its rows. If not, a better approach is:
2) You can use events to communicate between the views. Let's say you have a title div at the top of the page, which needs to be updated whenever a "title" text input changes ... but that text input is way down the page and doesn't conceptually have much to do with the page's title (apart from setting it). The common point between these two elements (and their views) is the data, the text of the title itself.
Now imagine that titleDivView and titleSettingInputView both share a pageTitle model. When titleSettingInputView calls this.model.set('titleText', 'newTitle'), the titleDivView can listen for this.model.on('change:titleText', ...), and re-render itself appropriately in response. In this way two totally un-connected, de-coupled views can interact with each other, without creating a tangled web of inter-related code.
And of course, if there isn't a nice convenient "change:title" event to bind to, you can always make your own, as with the custom "presync" event I described above.