I am wondering how to structure a KnockoutJS application the right way.
The official documentation almost always uses just one single ViewModel!
After only a few implemented functions my code became very confusing and coming from an object-oriented background I am very allergic to architecture like that. So there must be a better solution.
Being not very experienced with JavaScript I was searching Stackoverflow and found those three options. So I tried the first two options and I am not happy with them:
Having multiple ViewModels like here.
I find it very difficult to decide what DOM-element gets what ViewModel. Also there were several functions called from outside the DOM-element. Maybe I used too little ViewModels with this kind of architecture but communicating between ViewModels seemed to be different and somehow shouldn't be necessary I hope. So how to do that properly?
Having sub views and utilizing the with binding (the second option from those three).
This was my preferred type of architecture because you can have document-wide bindings out of one view model but you can also structure your code into sub-chunks and bind them to wherever you want by using the with binding. This option though requires object literals instead of functions, which are inferior as described in this answer.
I haven't tried method three because it seems a little overkill and also uses object literals.
So is there a method to structure my code and also have full control without using object literals?
I hope this was not too confusing :-P
For any of the options that you mentioned, you do not need to use object literals. The samples just used them to simplify the code. You can choose to create the individual view models in any way that you see fit.
For example in #3, you can use a constructor function like: http://jsfiddle.net/rniemeyer/PctJz/149/. Of course, the actual data would get passed into the function rather than being static. Same with #2, you just would have it wrapped in the "View" object.
Related
Is there any difference between class and staticClass in Vue.js render functions? Using Template Compilation, I can see that it outputs different results depending on what is passed to HTML class attribute.
For example, when I pass a single string (for example 'foo') it outputs staticClass in data object:
<div class="foo"></div>
compiles to:
function anonymous() {
with(this){return _c('div',{staticClass:"foo"})}
}
but when I add a colon : (shortcut for v-bind) in front of class attribute it outputs class:
<div :class="'foo'"></div>
compiles to:
function anonymous() {
with(this){return _c('div',{class:'foo'})}
}
I am curious about the difference between class and staticClass, and which one should i use when writing own render functions.
I have googled a little, but have not found any clue.
Thanks in advance.
The key difference is that staticClass can only be a string. class supports all the other formats, such as arrays and objects.
The class attribute is special in many ways. For most attributes you can't specify both a bound and non-bound version on the same element. It also needs to be merged differently when combining the attributes from nested components. All of this merging happens here:
https://github.com/vuejs/vue/blob/531371b818b0e31a989a06df43789728f23dc4e8/src/platforms/web/util/class.js
When templates are compiled down to render functions they employ a number of undocumented features to take advantage of extra knowledge that comes from the template. This would be one such example, where it knows that an unbound class can only be a string so it tries to retain that knowledge by storing it separately as staticClass.
In theory there are a couple of advantages to that:
Manipulating the value doesn't need to worry about the array and object forms of class.
The staticClass can never change, so there's no need to check it when updating the DOM.
However, in practice that second optimisation isn't implemented (there's something that looks similar in the template compiler but it's not quite the same thing). Further, it's not entirely clear from looking at the code that there's much gained from a manipulation standpoint either. If anything it looks like it just makes things more complicated trying to maintain the two separate concepts right until the last possible moment. Perhaps the benchmarks suggest otherwise...
As for which one you should be using in your render functions, only class is documented so I'd stick with that:
https://v2.vuejs.org/v2/guide/render-function.html#The-Data-Object-In-Depth
I know enough jQuery/JavaScript to be dangerous. I have a JSON array that I'm interacting with using two different elements (a calendar and a table, to be precise). Is there an event handler (or any other way) I could bind to so that the table would refresh when the JSON changes?
Basic programming, parse the json (=string) into a javascript object or array. (you probably have already done that.) Use an implementation of the observer patern.
I suggest taking a good look at #Adam Merrifield 's interesting links.
Most of the time using getters and setter where you can fire a custom event (or call a callback method) inside a setter is the key in this.
KnockoutJS is a good framework to help you do such binding. It also uses the observable - observer/subscriber pattern.
using timers is not a really good idea.. little to much overhead. (doing stuff also when nothing gets changed. And you will always hop x ms behind (depending on the polling frequency).
You might want to consider Knockout.JS
It allows bi-directional mapping, so a change to your model should reflect on your view and vice/versa.
http://knockoutjs.com/documentation/json-data.html
However, it might be late stages of your dev cycle, but something to consider.
I seem to often be making the decision to create objects in javascript that are basically the ModelView or Model objects in an MVC architecture. So when the user changes their properties or whatever via the webpage, the javascript object's properties are changed, and then the javascript object is submitted to the controller. The main reasons I am using this approach are:
Increased flexibility of display.
Alternatively, everything is done
with forms so that I can easily post
them back to the controller. Forms do
not allow various display options
such as wrapping around other
elements and so on.
I am using a lot of javascript
anyway. I have to manipulate the
elements whenever buttons are pressed
(like swapping two list elements
around). I also usually hijack the
buttons and use them with ajax.
The default model binder rarely works
on complex objects so I need to
maintain two sets of objects anyway.
It is easier to perform complex
validation on a javascript object
compared to html.
Are there any libraries or techniques or approach that assist with this approach? Maybe JSON.NET? Do any people try to avoid this approach?
I haven't taken this approach myself but there are some frameworks that sound similar to what you are proposing. The one that looks most interesting is Knockout JS. It provides data binding to your model among other features.
I've recently started using Backbone.js. I like the architecture, in terms of features it's almost exactly what I need...
... However I found the following caveats:
For Collections get means something different than for Models. There is no set. Attributes should be accessed in a regular way. I find it rather inconsistent. It's easy to confuse models and collections sometimes. Is there anything that can be done to overcome this?
Assigning initial values inside Model.extend doesn't always work. For example assigning url will not override the default behaviour. This can only be achieved through a call to set() method. Again very error prone.
I still don't know whether it's required to use get/set inside initialize() call.
I don't understand why I can't just call _.bindAll(this) inside initialize() and I have to list specific function names to be bound like this: _.bindAll(this, firstFunc, secondFunc, ...). This is not very DRY.
I would like to know: what are the best practices regarding the mentioned situations? What do you do to make the framework more consistent - any monkey patching? Am I doing anything wrong / against the convention?
I'd be grateful for any good real world examples. I did find this: http://documentcloud.github.com/backbone/docs/todos.html and http://liquidmedia.ca/blog/2011/01/backbone-js-part-1/ and those don't address any of the mentioned problems. In fact they just present the simplest ideas and absolutely no border cases, so anything more complicated could be useful.
EDIT:
Ok, and there is one more fundamental think I don't understand:
Am I ever allowed to place additional attributes on extension like this: var SomeModel = Backbone.Model.extend({ myattribute: myvalue }) ?
If so, then why don't subsequent calls to new SomeModel().get("myattribute") work ?
What exactly is this inside initialize() ? Is it model class or model instance ?
EDIT(2):
Well, I found this: http://maccman.github.com/spine/. It looks like Backbone.js 2.0, shares a similar name too :). Haven't tested it yet, which might be a bit of a show stopper, as the library is very recent. However from the docs side of things it looks very promissing. It gets rid of most of the problems that I found, it simplifies the API, it even gets rid of the dependency on underscore.js which for a library is a good thing. I'll post my further findings here.
Ok, I think I can say it quite confidently now: Backbone is dead, long live Spine.
Spine isn't exactly a fork of Backbone. It is however very similar and clearly inspired by some of the design decisions. It could be said that the author tried to retain as much as it was possible the original backbone API, getting rid of everything unnecessary or illogical. I find it also easier to extend. The list of changes includes among other things:
Getting rid of the dreaded Collections. "class methods" are used instead,
Getting most out of js prototypical nature (i.e. no get/set is needed). Attributes are accessed directly. An explicit call to save() is required in order to trigger an event.
Views and Controllers are now merged into new type of Controllers together whose purpose is to respond to DOM events and bind to model events.
The name :)
I find those design decisions coherent and sensible.
The reason there is no 'set' for Collections is because Collections are not arrays, they are sets, which are potentially ordered. The only supported way to place an element at a particular position is to add it to the collection and then sort the collection.
I've started to wrap my functions inside of Objects, e.g.:
var Search = {
carSearch: function(color) {
},
peopleSearch: function(name) {
},
...
}
This helps a lot with readability, but I continue to have issues with reusabilty. To be more specific, the difficulty is in two areas:
Receiving parameters. A lot of times I will have a search screen with multiple input fields and a button that calls the javascript search function. I have to either put a bunch of code in the onclick of the button to retrieve and then martial the values from the input fields into the function call, or I have to hardcode the HTML input field names/IDs so that I can subsequently retrieve them with Javascript. The solution I've settled on for this is to pass the field names/IDs into the function, which it then uses to retrieve the values from the input fields. This is simple but really seems improper.
Returning values. The effect of most Javascript calls tends to be one in which some visual on the screen changes directly, or as a result of another action performed in the call. Reusability is toast when I put these screen-altering effects at the end of a function. For example, after a search is completed I need to display the results on the screen.
How do others handle these issues? Putting my thinking cap on leads me to believe that I need to have an page-specific layer of Javascript between each use in my application and the generic methods I create which are to be used application-wide. Using the previous example, I would have a search button whose onclick calls a myPageSpecificSearchFunction, in which the search field IDs/names are hardcoded, which marshals the parameters and calls the generic search function. The generic function would return data/objects/variables only, and would not directly read from or make any changes to the DOM. The page-specific search function would then receive this data back and alter the DOM appropriately.
Am I on the right path or is there a better pattern to handle the reuse of Javascript objects/methods?
Basic Pattern
In terms of your basic pattern, can I suggest modifying your structure to use the module pattern and named functions:
var Search = (function(){
var pubs = {};
pubs.carSearch = carSearch;
function carSearch(color) {
}
pubs.peopleSearch = peopleSearch;
function peopleSearch(name) {
}
return pubs;
})();
Yes, that looks more complicated, but that's partially because there's no helper function involved. Note that now, every function has a name (your previous functions were anonymous; the properties they were bound to had names, but the functions didn't, which has implications in terms of the display of the call stack in debuggers and such). Using the module pattern also gives you the ability to have completely private functions that only the functions within your Search object can access. (Just declare the functions within the big anonymous function and don't add them to pubs.) More on my rationale for that (with advantages and disadvantages, and why you can't combine the function declaration and property assignment) here.
Retrieving Parameters
One of the functions I really, really like from Prototype is the Form#serialize function, which walks through the form elements and builds a plain object with a property for each field based on the field's name. (Prototype's current – 1.6.1 – implementation has an issue where it doesn't preserve the order of the fields, but it's surprising how rarely that's a problem.) It sounds like you would be well-served by such a thing and they're not hard to build; then your business logic is dealing with objects with properties named according to what they're related to, and has no knowledge of the actual form itself.
Returning Values / Mixing UI and Logic
I tend to think of applications as objects and the connections and interactions between them. So I tend to create:
Objects representing the business model and such, irrespective of interface (although, of course, the business model is almost certainly partially driven by the interface). Those objects are defined in one place, but used both client- and server-side (yes, I use JavaScript server-side), and designed with serialization (via JSON, in my case) in mind so I can send them back and forth easily.
Objects server-side that know how to use those to update the underlying store (since I tend to work on projects with an underlying store), and
Objects client-side that know how to use that information to render to the UI.
(I know, hardly original!) I try to keep the store and rendering objects generic so they mostly work by looking at the public properties of the business objects (which is pretty much all of the properties; I don't use the patterns like Crockford's that let you really hide data, I find them too expensive). Pragmatism means sometimes the store or rendering objects just have to know what they're dealing with, specifically, but I do try to keep things generic where I can.
I started out using the module pattern, but then started doing everything in jQuery plugins. The plugins allow to pass page specific options.
Using jQuery would also let you rethink the way you identify your search terms and find their values. You might consider adding a class to every input, and use that class to avoid specifically naming each input.
Javascript is ridiculously flexible which means that your design is especially important as you can do things in many different ways. This is what probably makes Javascript feel less like lending itself to re-usability.
There are a few different notations for declaring your objects (functions/classes) and then namespacing them. It's important to understand these differences. As mentioned in a comment on here 'namespacing is a breeze' - and is a good place to start.
I wouldn't be able to go far enough in this reply and would only be paraphrasing, so I recommend buying these books:
Pro JavaScript Design Patterns
Pro Javascript techniques