JavaScript – Page 9 – Longing to know

After my brief primer (Part 1) of the things I’m looking to accomplish with Angular in what I consider a large-scale application, I’ve had a week or so to toss around ideas and get a solid foundation.

To recap, I want this application to avoid becoming an unruly, behemoth that is unmanageable. I want core, reusable components to be separated from core functionality. That is to say, I want loose coupling. The application should have hooks, navigation, and what not that is self-aware while allowing multiple developers to create their own discrete set of functional areas. In that vein, or to that end, I want “areas” to be independent for the most part and, as such, developers should be able to work on the individual functional areas without stepping all over each other’s code, or worrying much about breaking other parts of the application.

More Link

This week, my team and I have embarked on a new large scale application. It’s predominately your typical web multi-tier web application with business logic, security, CRUD, and what not.

However, it’s also going to be an Angular Single Page App (SPA). Thinking about the structure of this application, in terms functional blocks and project/solution layout is pivotal in the design and engineering process.

More Link

Earlier today, I started looking at Angular 2.0 and the differences with Angular 1.x. The primary difference, aside from API changes, is that Angular 2.0 uses ECMAScript 6 (ES6 JavaScript).

ES6 is quite different from ES5. To be honest, I am still wrapping my head around the differences between ES6 and ES5. From a cursory perspective, many components/modules/elements that previously required JavaScript libraries are now native. Additionally, ES6 is more class driven than ES5 and supports observables.

More Link

After Ignite, and especially after viewing the the latest features of VS2015 RC, ASP.NET 5.0, and .NET Core 5.0, my interest in Node.js was finally piqued. Admittedly, I had mostly ignored Node.js up to this point. As a primarily Angular/JavaScript developer, the aspect of using JavaScript for server-side is becoming increasing appealing.

Let me preface this by stating that I’m a noob when it comes to node. This really is my first time diving into its feature set.

For a brief history, Node.js is a runtime environment that uses the Chrome V8 JavaScript engine to execute JavaScript on a server. This also provides web hosting and other niceties to run both console apps and web-hosting apps. Spinning up, for example, an API through Node becomes a pretty straight-forward and powerful capability.

More Link

While working with an Angular application that involved selecting rows in a table with checkboxes, I found that the requirements necessitated having a ‘select all’ checkbox.

Selecting all elements is a common, and usually pretty easy, mechanism to incorporate. But, if you want an indeterminate, or tri, state, for your top-level checkbox selector, it becomes a little more involved.

More Link

When I’m online with my banking site, or Pandora, I occasionally get those nice dialogs asking if I’m still around after being idle for a while. Sometimes, I think it’s a nuisance, but it can be a helpful security measure. It can also be beneficial in SPA-type applications.

With SPA’s, the user can perform so many actions in the browser that never make requests of the server. As a result, if we’re using a cookie-based security mechanism that has a short expiration time, they could be effectively logged out and not even know it.

This is a problem.

More Link

A few weeks ago, I made this nice little side-bar that allowed a user to click an element and then perform actions on that element. They could also add new elements.

The idea of showing a quick animation for when a new element is animated using Angular’s animation framework sounded easy. However, it turned out to be problematic.

More Link

If you’ll recall my previous post on building a simple menu navigation system with Angular, I alluded to advanced scenarios such as determining when, or if, a user can navigate away from the current state.

There are many ways to prevent a user from changing state, but providing reusable mechanisms/services to achieve a unified solution should be our goal.

More Link

One of the best features of Angular is also one of its most impactful on performance. That feature is two-way binding.

To achieve two-way binding Angular “watches” for when JavaScript objects change and when the DOM values change during Angular’s digest cycle. It’s not an extremely complex mechanism, conceptually, but it’s very effective.

More Link

Previously in my discussion of how I like to use the ui-router and states for basic layout functionality, I touched on the basic tenants of what I see as prominent in many SPA applications. In this discussion, I’d like to dig a little deeper and illustrate a simplified implementation of a menu navigation system.

In developing a menu navigation system, I initially consider how flexible I need the navigation to be. If users can change states with hopeless abandon, then define your states and use ui-sref and nothing more. If we need more functionality, we need a more robust solution.

More Link

Longing to know

Building large scale Angular Applications (Part 2)

Building large scale Angular Applications (Part 1)

Using ES6 script now

Exploring Node.js

Angular tri-state checkbox

User Session Timeout

Animating and Angular Repeater Finish

Advanced Angular Navigation with ui-router

Optimizing Angular App Bindings

Simple menu with ui-router states

Category Archives: JavaScript