Posts

Showing posts with the label RequireJS

Improvising Angular + Require template

Sometime back I wrote a post on using Angular and Require to create a project template. The idea was to make the application more modular and broken down into multiple components that can be easily reused. I have made some more modifications to the template, especially the naming conventions used for files and minor changes to the structure of the project.

Angular + Require project template

Image
I've been working on an Angular project for good number months. There's a lot that I've learned and I've realized that the code I wrote could have been structured in a better way. I wanted to write this post sometime back, however I thought it would be better to create an application structure first and then post my learnings. I have posted all the code on github here - https://github.com/sagar-ganatra/angular-require-template. The template is still a work in progress, however the basic structure of the template is in place.

Lazy loading AngularJS components using Providers

I've been working on an Angular project for sometime now and I usually run across issues when building the application. In most of the example applications that I've seen, all application script files are loaded upfront i.e. all JavaScript files are loaded when the user accesses application. I get annoyed by this approach; why should all the components be loaded upfront when the probability of user accessing the entire application is very less. How does one architect a multi-page application using Angular? What would be the size of the application after minifying all the JavaScript files. Most importantly how does one load the components lazily. I've used RequireJS in my previous projects and it allows you to load components on demand; the idea is to load components based on the selected route. I've tried a similar approach with Angular using 'resolve' property in the $routeProvider.

RequireJS - Busting the browser cache with every deployment using Grunt targethtml plugin

The projects that I work on have deployments to the QA very often; testing out the bug fixes and new features. Every time after the deployment, I ask the QA to clear the cache, since all JavaScript files are cached by the browser. This is really frustrating to QA and I needed someway to clear the cache with every deployment. This would be same in a continuous delivery project, wherein the client would be required to clear the browser cache.

Client side MVC: Using Publisher - Subscriber event model to build decoupled components

Image
I've been really busy these days writing client side MVC code. A few months back I explored using Require and Backbone to build the frontend MVC structure. Since then I've been working on improving the structure of my client side code. One approach that I've used is to decouple the components. When I say decouple, the components that I build should not directly alter or affect the behavior of some other component in the page. By decoupling the components, we can ensure that these set of components can be reused and tested in isolation.

Applying MVC to your frontend application using Require and Backbone

Image
I've been looking into BackboneJS for quite sometime now and thought it would interesting to build an application using the MVC pattern. Although Backbone provides various components - Models, Collections, Routers and Views; it doesn't provide a framework that can help you to structure the application using these components. While working on this application, I realized that I can separate these components in such a way that they can be made reusable or rather loosely coupled by defining the components in separate files. However, there was an interesting problem that I came across where the Views had a dependency on the Collections to be loaded first and then render the template data. I had read a little about RequireJS that allowed modules to be loaded asynchronously and also in resolving dependency. Thought I would give it a try and see whether it addresses this problem.