I'll preface this with that I'm new to AngularJS and still learning the best practices.
What is the best practice for integrating existing JavaScript features/plugins/code into an Angular application?
For instance when should the integrated JavaScript fire if a normal implementation fires when the DOM is ready?
Or should it be rewritten as a directive or can the JavaScript be used without any changes?
In my experience I have tried to follow instructions for using scripts such as JVFloat or SkeuoCard with limited success out of the box. I've been able to hack them into my code, but I'm not sure what the best practice would be.
Angular is a fairly large script, but it helps drastically reduce the amount of code needed for most projects. That said, it is likely that other libraries/plugins you are considering will be much larger than if you were to rewrite them using the power of angular. The Angular devs strongly recommend taking full advantage of the framework to offset its large size. The theory is that if you do this properly, Angular will save you bytes, not cost them.
To cleanly use external plugins, you'll need to wrap them as angular directives, so there is a bit of adaptation necessary that point. I have actually seen this done in a manner that was more verbose than if the developer has not used the plugin at all. It's not that it required a lot of code to wrap the plugin as a directive, it's just that the functionality of the plugin is so easily reproducible with Angular that the plugin was nearly useless.
Regarding DOM ready: Thinking the Angular way has a bit of magic about it. Because of the power of directives, $watch, promises, and data-binding, you don't think as much in terms of timing as you do relationship. If all is done well, the updates and behaviors will occur when they can (data is served, things are loaded, etc) and everything is updated automatically. Just build a simple app and you'll quickly see that Angular makes complex systems a cinch.
You might also be interested in this previous answer of mine: What does AngularJS do better than jQuery?
Related
I am new to React js and I have been trying to understand what real problem does js frameworks like React,Angular solve and why one need to learn them.
Of Course when i see advantages of framework everybody talk about "Shadow/Virtual DOM, Router, Reusable Components etc" , but then I stumbled upon below links which talk something different
https://medium.com/dailyjs/the-deepest-reason-why-modern-javascript-frameworks-exist-933b86ebc445
https://www.codementor.io/binarymuse/react-components-from-a-jquery-programmer-background-du107k2lz
but they were not clear to me
So i am meaning to understand how difficult it was to maintain js/jquery code before these framework came by.
Everybody is just asking to learn these frameworks because they are popular but none of them clearly explains why they are popular and what problem they solve and how they make our life easier when it comes to creating web-app from scratch.
Others have already mentioned the advantages and what these frameworks resolve.
I wanted to add what problems they can create:
I have seen many people that use a framework see it as a hammer and every website as a nail. In other words they either don't or can't figure out that in many cases a framework is not needed. I have seen web pages that are nearly 90% static data still download an entire framework just to provide drop menus or something else trivial.
Frameworks force you into a lifecycle and development style that, in some ways, make some things easier and other things much, much more complicated. AngularJS had a nasty digest cycle that often led to complications. Redux forces you to write much more code than needed just to handle state that on many pages is not needed. Vue, React, Angular all force you to either use their data creation functions, their way of rendering or their way of handling inter element communication. And none of these are faster than vanillaJS. Even virtual DOM has its issues.
The size of a framework is often much more than needed. I have several small libraries that do the majority of the work that a framework does but my code is in the sub 5K range if I load it all.
Some people that learn a framework first can not figure out how to write in raw JavaScript. They also tend to learn sloppy ways to write code. No, not everyone, but a large number people that did not start with vanilla JS write code that tends to be much larger and sloppier than needed.
It is best to avoid JavaScript except where really needed. Often I can use raw HTML and CSS to do everything I need to do. I find that it is rare that I need to use much JavaScript even in projects that exceed several thousand files. It is faster to allow the browser to process HTML and CSS, which all processes at compiled speeds and only use JavaScript for things you can not do in HTML and CSS.
You don't "need" to learn them, but many people and companies use them. The main advantage is being able to have your entire site on a single webpage, where you just modify the data and it handles changing the elements on the page for you. For instance, you can just think about "put the user's name here, and when they click the button, add another list field there", but you no longer have to think about "get this DOM element, set its innerHTML to the user's name, and when they click the button, create a new DOM element for input, another one for the label, get the container element, append the new children". It also allows you to more easily bind data to DOM elements, so you can just say "this field is for the variable 'numberOfItems'" instead of worrying about grabbing the DOM element and its value and storing it into numberOfItems when you need it; with React/Angular/etc. that variable will always be up to date with the user's input without you needing to update it.
TL;DR: The frameworks are not necessary, but they help automatically handle a lot of common, tedious DOM manipulation for you in a way more optimized than you'd likely end up implementing yourself, with less code for you, and all on a single page instead of having to reload the page every time you want to display new data or a new layout.
What is React JS?
ReactJS is an open-source JavaScript library that is used for building user interfaces specifically for single-page applications. It’s used for handling the view layer for web and mobile apps. React also allows us to create reusable UI components.
React allows developers to create large web applications that can change data, without reloading the page. The main purpose of React is to be fast, scalable, and simple. It works only on user interfaces in the application. This corresponds to view in the MVC template. It can be used with a combination of other JavaScript libraries or frameworks, such as Angular JS in MVC.
https://www.c-sharpcorner.com/article/what-and-why-reactjs/
This is a wide discussion about frameworks in general. Is easy to say React, Angular and so on makes easier to manipulate DOM elements and reuse components, but to apply frameworks usually are about if solve your problem.
in javascript we have load the webpage by using location.href but by using angular/react we the page updates automatically.
I'm new to angular. Some forums and tutorials show how to integrate jquery plugins in angular. Actually there are plenty of jquery plugins. I used a lot of jquery plugin in my previous projects which were implemented only in jquery. So I would like to get that feel (colors,UI, animation...) into my angular 7 project. But in the middle, I'm worrying that some forums say "Don't mix jquery plugins with angular"
So may I import jquery plugins inside angular? Will it be a problem? For Eg : Datatable has a lot of function where I need most. Jquery Confirm Master gives a better UI. And there are a lot of API calls also. If I need to use these kind of jquery plugins, what can I do?
There are some core reasons you shouldn't access the DOM directly in Angular (as you do with Jquery). I answered a similar question here
Angular is a fully blown framework where you shouldn't differ from the 'Angular way'. There are several reasons for this. For one your code will become very complicated in the way it works. Some things you do in Jquery is very hideous compared to how simple you can implement the same thing with Angular. Another reason is that Angular applications are not always meant to be ran in a browser. For example you can run Angular in a web worker, which doesn't have direct access to the DOM. Your components will become dependent on Jquery when there is no need to, which might hurt you if you want to reuse those components in other Angular applications.
Your value point for sticking to Jquery is that you can reuse that code. To that I will say that you should rewrite those components for your Angular application so you can later reuse those components in other Angular applications. Modernize / rewrite your components now, so you have optimized clean Angular components. You will quickly find that your Jquery code is overly complicated compared to how you do similar things in the Angular framework.
We are using Dojo (1.9.3) as a JS framework for building a single page application. We are however spending too much time on the quirks of Dojo, so even simple tasks take a long time to implement. And since there is lack of proper documentation, we often have to resort to reading the source code and then implementing a workaround.
I feel that we would speed up development, and make it easier to maintain the code if we moved to some other framework. Our codebase is rather large, since it is a complex application, so we do not have time to re-write the whole thing at once. I was therefore hoping that it might be possible to combine Dojo with some other framework, so that we can move away from Dojo incrementally. I have only dabbled with these other framework in my spare time, and only wrote some small example apps, so I do not feel that I can really say whether or not they would play well with another framework, so I'm hoping that some of you out there can.
The frameworks I've been looking into - in the order of what I'd prefer based on my short investigation, but feel free to convince me otherwise.
Ember
React
Polymer
Angular (last due to me being scared of the major 2.0 overhaul)
While the main question is whether or not it is possible, please also advice on if you think it is a bad idea to do so.
The most I can say from the Dojo end of things is that Dojo itself is a toolkit, not a framework per se, and thus generally should not interfere with other scripts or frameworks. The reverse, on the other hand, can't always be said. So while I can't speak for all of the choices in your list, I do not think that Dojo itself will get in your way.
One possible exception I can think of is if any of the frameworks in question augment native prototypes, particularly Object, since that will affect enumerable properties in all objects and can wreak havoc on any scripts that use for...in loops without hasOwnProperty.
The only other exception I can think of is whether any of the frameworks in question for some reason do not coexist well with an AMD module loader.
That being said, I would also advise you to take the "promise" of frameworks with a grain of salt - you say that right now you are finding that implementing things with Dojo takes effort, and naturally the frameworks you list are attractive because they make certain parts of application development easy by offering patterns and conventions - but the question you should ask is, how hard does your framework make your job the moment you need to do something outside or against those conventions? Dojo may have a learning curve, but it generally doesn't prevent you from doing anything.
You can use them together, but it also depends on what you're trying to do. Some actions might take more time for integration than others.
Dijit
I only have experience with Ember.js and AngularJS, but a common concept in these frameworks is data binding. Data binding allows you to simply update the model and the view will reflect the changes in the model.
However, these usually do not work nicely with widgets. Widgets (like the Dijit library) create their own DOM and because of it, frameworks like Ember.js or AngularJS are not "aware" of these changes and cannot update the view in that case.
To make it work, you will have to wrap your widgets into components (Ember.js) or directives (AngularJS). An example of such wrapping can be found in this answer.
Dependency loading
Dependency loading might be confusing. AngularJS comes with their own dependency injection system, and means that you will have to use the Dojo AMD loader for Dojo modules and AngularJS dependency injection for AngularJS. The two work nicely together as far as I know (I've seen examples with the RequireJS AMD loader, so it should be possible).
With Ember.js I had a bit more troubles integrating with the AMD loader. The creator of Ember.js (Tom Dale) does not believe in AMD, and I've seen several issues trying to load Ember.js components with an AMD loader.
It all depends on how you wish to use these frameworks and what extra effort you want to make. To me it looks like you're not even sure what to use these frameworks for, since React.js or Polymer has a completely different purpose than AngularJS or Ember.js for example.
I'm currently building a frontend architecture for quite a big site (9 digit monthly pageviews). One of the requirements is ability to fast changes as the businessfield changes, so I'd want to keep everything as lean as possible and thus am pondering about forgoing full-on MCV framework and just using jQuery (plugins) instead.
Here's how it would work:
First pageview, server renders the full page (in order to support crawling) - Loads data, renders it into template (mustache) and that into layout.
If history API is enabled, then next pageviews will be rendered with Javascript (data+mustache template), no hashrouting here (due crawlers). If not, then everything will be rendered serverside.
So, as clientside routing basically won't be needed at all, full-on MVC framework seems like a overkill.
So, here's what I'm thinking - Just do the data-loading & rendering as jQuery plugin. I'm currently even thinking about forgoing databinding as well, as the site is more about content than complex functionality, which would simplify the structure even more. Data changes could just be handled with re-rendering the content.
What kind of pitfalls does this approach have in such scale?
There are two general approaches:
First one - If your main requirement is ability to fast changes as the businessfield changes using an MVC framework might spare you a lot of grief in as using one of those leads to much cleaner and easier to maintain and extend code, even if you don't use all of its features, i. e. routing. Backbone is a good choice, if you're looking for a simple lightweight framework. On the contrary, when things start to become more and more complex, managing a growing jQuery application becomes increasingly harder, in comparison to backbone, angular, etc.
Second one - is stated in a nice abbreviation of YAGNI - You Ain't Gonna Need It. If you're certain you won't be delving in some complex frontend features, that requires data bindings, event composition, routing etc. in the forseeable future - why even bother considering MVC frontend framework? They are designed mainly to simplify creation of complex frontend applications, not to make simple things more complex. If all you ever gonna need is load server-side data and pass it to a template - then you might not even need jQuery for this, and do just fine with pure JavaScript.
So after all it's up to you to decide, does the complexity of your project call for more advanced tools, or you'd be fine with simple ones.
I've been asked at work to convert a popular mechanical engineering excel application to a single page web application. It requires no database so my idea is to put everything on the clientside in javascript.
First version is gonna be pretty small but more complexity will be added further along. Canvas graphics is gonna be drawn in realtime as user changes input. So performance is important. My question is: Should I use a MVC framework such as Angular JS? Or is it better to stick with Jquery? If I should use a MVC, which one is best suited for this app?
Everyone at my company uses IE9 so I dont need any support for older browsers.
Angular bills itself specifically as a way to build CRUD apps - basically database front ends. The app you're describing doesn't sound like it's doing a ton of that, so Angular would probably be more trouble than it's worth.
jQuery is a helper library - it makes dealing with the DOM easier, but doesn't do a thing to provide overall structure to your application. jQuery is a "necessary but not sufficient" in my book - you're going to want it, but it's not enough on its own.
Personally, I'd lean more towards Backbone, specifically because it's so minimal - it gives you some useful data binding stuff and some hints on how to organize your app, then gets out of your way to let you build the abstraction you want. Based on the fact that you mentioned the original is in Excel, some sort of data binding / change notification system is going to be important. This way you can emulate the spreadsheet's "change a cell and the chart redraws" system that everyone's already used to.
In the end it's hard to say without more detail on the app in question, and what kind of calculations / how often they have to happen are. Figure out what your app architecture should be, find (or build) a library that helps implement that architecture. It might be MVCish, it might not.
Well jQuery will get very messy as complexity increases. Angular JS is an amazing library but there are also a myriad of different ones out there. Depending on the Mechanical Engineering principles you are working with using AJAX may prove to be more perform-ant, due to the lack luster power of some older browsers.
It really depends on the complexity of the calculations, but in terms of dealing with events and managin the structure I would suggest using Jquery as well as Angular on top of it. then make the decision about whether or not to move some functions to the server or not, based on performance.