This sounds like a stupid question, but thought I would post anyway...
I am just making a simple web app with javascript and html and decided upon Knockout JS for the main framework to manage the UIs. However I am a bit puzzled how to proceed.
My first page is a very simple login page, it just has a username and password box, the problem comes when I want to do thing with the UI. An example would be adding a watermark to the ui boxes, or adding logic around listening to custom events, I could just write it as in-line javascript but I cannot really unit test any of it then.
Originally I was planning to use an MVC style pattern so I could unit test the controller with a mocked view, and just put any ui logic in there.
So is there any acceptable way of doing this without putting it all as in-page logic?
The way mvvm works is that the view should pretty much be a visual representation of that view model, so put your logic in there. If you design it right so your functionality is contained in seperate classes then you can mock them all out easy enough. If you are used to MVC then just see the viewmodel as your controller.
I can see where you are going with your question though, as with complex views you could end up with quite a lot happening within your ViewModel class, but if you just stick to simple oo and encapsulation principles you wont go too far wrong...
So anyway to summarise, put it in your logic in the view model.
There are two approaches you can use. There is an xUnit package for JavaScript called JsUnit So it is possible to unit test your JavaScript-based UI logic. The other route as you mentioned is to use the controller to contain the logic and the JavaScript as a "pure" view model. I personally feel that either approach is viable. You just want to make sure that your JavaScript-based view model doesn't become too intimate with the view. :)
Related
I'm a beginner in Javascript and web development in general. I'm building a web app that must be highly interactiv, so most of my work is about using Javascript to make this happen.
After having already written a good chunk of code, I feel like it won't be really maintainable and it's already hard to change, because I don't think I organised my code very well.
Essentially, I'm looking to separate the code that does actions on my objects, and the code that displays my objects. I've found that the Widget Factory might be a way to do that, but I can't really understand what it does exactly.
I red lots of documentation on it, but I don't know if it will be of any use for what I want to do.
Can you tell me if it will be useful for me, and if not, what other tools or tutorials I should get my hands on to achieve this ?
Thank you
The widget factory is used to define custom jQuery widgets.
Your questions is very broad and generic to answer, since only you know what kind of objects/models and what kind of interactivity you are expecting to have between clients and the page.
In general you should create widgets when you are implementing a generic solution.
A widget is meant to be something re-usable that handles one particular think/job.
For example if you want a "rate this comment" thingy in your page were users can rate other user's comments, you would create a rate-comment widget and apply it to all your user-comment elements.
I’ve been searching for the best way to handle modals in angular and I'm getting the impression that they need to be separated from controllers in order to achieve separation of concerns in MVC.
However when it comes to implementing this using a directive or a library out there I don't see the need for such massive overhead of adding so much code. Effectively it seems as though we are doing exactly the same thing but with more calls and events kicking off as compared to directly showing a bootstrap modal in the controller or service using jQuery as easy as:
$scope.saveChanges = function () {
$('#messageTitle').text('Done');
$('#messageText').text('Changes have been saved.');
$('#message').modal()
}
Porting a directive to handle the dialog is in effect showing the modal with additional steps and setups between dependencies etc. within angular, external libraries and/or custom code (whichever way it is applied). It's really like having a more simplified method call to a utilities method in some utils file that will just show the modal using jQuery. Again, I would be enlightened to know why this is not case which I expect from more experienced angular experts.
Apart from the fact that it is assumed a correct working way to do it, is there a reason why the DOM should not be referenced inside a controller. Could it have an effect on things like i.e. performance, buggy code, testing etc.?
I know that because it makes test cases easier is one of the reasons. Again, a valid reason however testing is not much of an issue having the DOM in business logic as in the code above if tested right. If there are, even more pressing cases for this, what are they? If any what is the best and most efficient way to achieve separation of the DOM from controllers/services if the same applies to services?
Background into current explanations:
What's the correct way to trigger jQuery DOM Manipulation from within a controller?
Separating DOM manipulation from Angular controllers - Best Practice wanted
AngularJS - why manipulating DOM in controller is a bad thing?
Why is it considered a bad idea to manipulate DOM in controllers?
From my understanding, these are the main reasons why a controller should not manipulate the DOM:
Testing. Test cases or test steps can be made well-structured and very easily testable when testing logic in controllers. Here what is tested is truly what a controller should be responsible for (Model manipulation).
Applying well-structured MVC code at the angular code base. Separation of concerns again gives a plus mark for testing but also makes code more manageable and well structured.
I would be happy to hear more detailed alternative answers to completely confirm and explain that any DOM manipulation what so ever is a bad thing within a controller. On the contrary it would be interesting to know whether there are exceptions. For the information of others and my attempt to answer, the reasons above are the most commonly known reasons and thus probably the only reasons to my knowledge, which fair enough are acceptable reasons at this point.
I have made a simple site which I now want to add a javascript overlay to do some relatively simple things such as:
Make the search box and pagination ajax driven to results can be loaded in without a refresh
Integrate the HTML5 history system
Add form validation
My coder has told me that I should use angular over jquery. When I look into it, it seems Angular is designed for large, completely AJAX driven sites, and ends up using jquery or jquery lite anyway.
My question is, does angular offer any significant advantages for my use case, to counteract the disadvantage of the learning curve and lack of community.
In my opinion there is no point for you to get hands dirty with AngularjJS for one small and rather simple project.
If you plan to extend your website in near future and continuously add new features than it is something to consider along many other options.
The beauty of AngularJS from what I've seen so far is that it's easy enough to drop into any project regardless of size. I've made a simple application like you described and it was still faster than just avoiding it all together.
We have been using Angularjs and saw that it saves much time of us in comparision with jQuery.
Angularjs uses Declarative programming for processing UI. It means that you only
need to declare your UI logic, Angularjs will process it for you.
See this link please: ANGULAR PHILOSOPHY
Now we still use jQuery in some cases but Angularjs is our top priority.
I advice you to learn and use it now.
I know this topic is likely to become subjective, therefore it is not about my particular web application I am working on.
For JavaScript, I haven't worked with MVC libraries like Backbone.js but I see the advantage in decoupling logic and views. On the other hand, it may just not be worth the time to learn the framework and adapt the application to make use of it. Moreover, handling all views in JavaScript makes SEO much harder, I guess.
So how should I decide whether it makes sense to use Backbone.js or a similar framework given the concept of a web application? On what depends the decision?
Any help to make the question more objective is welcome.
There are many client side javascript MVC (or MV*) frameworks out there. Most seem to have a different idea of what MVC is and how it should work together with your web application.
You should consider an MV* framework if the complexity in your client side javascript is becoming difficult to manage. If you have a team building a highly dynamic single page application (SPA) that does a lot of asynchronous communication with the backend then you will want to consider it. It's easy to end up with very messy javascript code otherwise.
An MV* framework will help you in one or more of the following ways:
by defining how the code should be structured. This is done to various degrees depending on how opinionated the framework is. Backbone for instance considers itself a library rather than a framework and thus leaves more of the decision making up to the user
by binding html to model. So if your data changes the page will be automatically updated (and vice versa)
by providing useful features such as URL history (for single page apps) and validation
I think it depends on your project. Here is a checklist which can help you in deciding whether you should use frontend MV* framework or not.
Lots of ajax request to backend
Many of your functionality doesn't require full page reload. Like adding a comment, pagination or infinite scroll.
You have models/REST API at backend. You can just replicate/use same structure at front end.
You are sharing logic/dom manipulation functions across different pages.
I will add more if I find any more points. This is what I can think right now and this is not a complete list. Any suggestions are welcome.
As You Know MVC structure can be included in javascript by using
backbone.js with
underscore.js and other similar libraries mainly focusing on each form field as property in an entity such that entities can be used different purposes MVC structure is maintained for easy manipulation in javascript
These structure good for event binding,dom manipulation ,serialization,etc
It depends on application's purpose for choosing which structure suitable whether its mvc or mvvm structure for javascript. MVVM structure can be included in the javascript through angular.js or knockoutjs or other libraries for dynamic binding to view component Javascript can be used
MVVM architecture will be usefull for maintaining form field binding without reloading or ajax There are a lot of application by maintaining the architecture in js and i have pointed out only a few .
for eg : Serialize form inputs to JSON using Backbone.js
In this example the form values are retrieved as model and then it can be manipulated and can add business logic and can be serialized or event binding and can do print or any thing
We need to change/rewrite an existing series of pages/workflow screens into one standard page. The project in itself will essentially be to build a single web page app inside the context of a larger existing application.
Our goal is to leave the server side implementation the way it is as much as possible. This means we won't be using a REST model, but rather just some form submissions to a java backend. Each end point will point to a JSP.
Each form will be created as a widget. When one widget submits it may affect the value of the other widgets which need to change their values on the fly.
It seems the 2 main options for single page web apps are Backbone.js or Ember.js.
Given our requirements, which of these 2 (or any other frameworks) will fit best? Or is there some other approach all together we should take?
Did you have a look at AngularJS? It is more comparable to EmberJS.
I would recommend you EmberJS for the moment, as it is more mature in term of ecosystem (Routing, Data, ...)
Backbone is lower-level than both precedents.
There are probably a bunch of things you should look into.
Emberjs is 42k minified+gzip while Backbone.js is just 5.6kb. Emberjs packs a lot of power in it which the barebones Backbone doesn't give you.
Analyse if you even need all those features. If your requirements are covered by just Backbone, IMO you should give Emberjs a pass. Shipping all those extra bits for no use is foolish.
With Emberjs, you will have to use jQuery as well. Not sure if you are already using it or not.
IMHO, I would use Emberjs if the single page web app is super complex with lots of feature requirements else Backbone should suffice.
Either will accomplish what you want.
I am partial to Ember as it provides a Routing/statechart framework which really helps lock an application's behavior down. Not to mention that it is MVC, which will help you separate your concerns. Each form or widget in your app will be a view that you define, binding inputs to your model layer.