Just starting out? Check out this guide!
Many times while building an AngularJS application you'll need to manipulate data, and it doesn't make sense to do it with a Controller method. Luckily you have Filters, which are particularly well...
In Single Page Apps we're used to fetch the data on event callbacks. That disables the capacity to use the URL to share it to someone else and get to the same state of the app, just like in non Sin...
Using Angular's ngClass directive you can dynamically assign classes to the HTML elements in your Angular application. This video will show you several different methods for taking advantage of An...
Creating your own services in AngularJS can be confusing. What are the differences between an AngularJS module's Service, Provider and Factory functions? This lesson shows how Angular's provider f...
Creating your own services in AngularJS can be confusing. What are the differences between an AngularJS module's Service, Provider, Factory, and Value functions? This lesson shows how Angular's va...
Creating your own services in AngularJS can be confusing. What are the differences between an AngularJS module's Service, Provider and Factory functions? This lesson shows how Angular's factory fu...
Creating your own services in AngularJS can be confusing. What are the differences between an AngularJS module's Service, Provider and Factory functions? This lesson shows how Angular's service fu...
Walkthrough the main differences between the ng-show and ng-if directives
When you implement a search bar, the user can make several different queries in a row. With a Promise based implementation, the displayed result would be what the longest promise returns. Here we s...
JSON from server often exposes raw data you have to transform to present to your end users. In this lesson, we cover a few solutions to make it happen.
Leaking logic in controllers is not an option, filters are a way to refactor your code and are compatible with ng-if and ng-show
showing All 334 lessons...
It is time to give our wishlist app some more depth. In this lesson, we will introduce the concept of groups and users. So that we can manage multiple users inside a group that can have a wishlist. Also, we will take a quick look at powerful features like union types and type discrimination.
In this lesson you will learn:
* Using the type map to store data by key
* Using literals to create single value types
* Combining literals and unions to do type discrimination
* Using Quokka as scratchpad for quick coding experiments
* Using enumerations
* Enumerations are just sugar for a union of literals
MST stores all data in a tree, where each piece of data lives at one unique location. In most state management solutions, this means you need to introduce weakly typed, primitive 'foreign keys' to refer to other parts of the state tree. But in MST you can leverage the concepts of references and identifiers to relate model instances to each other. MST will do the normalization behind the scenes for you.
In this lesson you will learn:
* The use of types.identifier to uniquely identify an instance of a specific type
* The use of types.reference to refer to data in another part of the tree, and with which you can interact with in another part of the tree
* The use of types.maybe to make as ".. or null" type
* Using types.late to create circular type definitions
In this lesson, we will set up Hot Module Reloading(HMR), making it possible to load new definitions for React components and MST models and apply them to a running application.
In this lesson you will learn:
* How HMR roughly works
* How to accept changes to components
* How to accept changes to changing model definitions, while keeping state
Let's stop hardcoding our initial state and fetch it from the server instead.
In this lesson you will learn:
* Set up basic data fetching
* Leverage the
afterCreate lifecycle hook to automatically run any setup logic a model instance needs to do after creation
In real life scenarios, many operations on our data are asynchronous. For example, because additional recourses need to get fetched. MST has first class support for asynchronous actions. We will start with a naively implemented async process, and work through async / await towards MST flows and generators.
In this lesson, you will learn
* That async process is painful if they need to respect the 'only actions can modify' semantics of MST
* Flows are the idiomatic way to describe async processes in MST
* Flows are robust; they make it possible to get full control over the lifecycle of a process
For an optimal user and developer experience, storing state in local storage is often a must.
In this lesson you will learn:
onSnapshot to get notified about new snapshots
* Storing snapshots in local storage
* Restore a state tree from local storage
* Verifying whether a snapshot conforms to a model using
It is time to add new entries to the wishlist. We will achieve this by reusing forms and models we've built so far.
In this lesson you will learn:
* MST is not limited to a single state tree. Every model can form a tree on its own
* Appending model instances to the state tree
We will expand our UI, and give the user the possibility to edit his wishlist. We will use the earlier defined actions. We also will use model clones only to modify data temporarily, and after approving the changes, apply them back to the original model.
In this lesson you will learn:
* How to call model actions from a component
clone to create a full, deep clone of any model instance
applySnapshot to update the state of a model instance given a snapshot.
Redundant data or caching data is a constant source of bugs. MST adheres to the philosophy that no data that can be derived should ever get stored. In this lesson, you will learn how to introduce views that declaratively derive data and which cache data smartly.
In this lesson you will learn:
* How to introduce views on models
* That computed properties are powered by Mobx computed fields
* How to combine MST with Mobx utilities like
To learn more about MobX basics check out my course, Manage Complex State in React Apps with MobX
Testing models is straightforward. Especially because MST provides powerful tools to track exactly how your state changes over time. Track snapshots, action invocations or even patches to verify the correctness of your actions!
In this lesson you will learn:
* To obtain immutable snapshots of the state using
* To record snapshots using
* To store and test modifications over time using
* Using Jest's snapshot test feature to verify snapshots and patches
* That MST can infer the type of a snapshot for you
Models are not just a nifty feature for type checking. They enable you to attach behavior to your actions in a straightforward and highly discoverable way
In this lesson, you will learn:
* How to define actions on models
* How to avoid
this issues by using self
* Models can only be modified using actions, and are further read-only from the outside
To learn more about TypeScript check out John Lindquist's wonderful course, Up and Running with TypeScript.
In this lesson, we introduce the running example of this course, a wishlist app. We will take a look at the core of mobx-state-tree (MST), models. Models describe the shape of your state and perform type validation.
You will learn:
* Defining models using types.Model
* Instantiating models from JSON using Model.create
* Primitive types: types.string & types.number
* Type inference for primitive types
* Composing models into a model tree
* Testing models using jest
When you async load a code-split component, sometimes it has associated redux actions and reducers that come bundled with it. We’ll explore a basic pattern for discovering async reducers that need to be “injected” into the redux store so that the component can function properly.
We’ll make the configuration changes needed in our express server, babel configuration, and react app code to get universal components working. We'll go from typical configurations to a "universal" configuration. We'll need our express app to use the webpack hot server middleware to serve our custom html. We'll use the
import function. And we can't forget to hydrate our React app on the client after we receive the serverside-rendered html.
We’ll make the webpack configuration changes needed to get universal components working. We'll go from a typical webpack configuration to a "universal" webpack configuration. We'll need two webpack configs—one for the client and one for the server. Each config needs several specific changes to be made to get universal working.
If you’d like to perform an animation while a component is loading you can achieve this by setting a minimum delay and forcing it to always happen. You can then use the onBefore and onAfter hooks on the component to set some local state within your parent component. This local state can be used to trigger the animation.
We’ll use a function as our first param in the
universal HOC. This function takes in the props and you can return a dynamic import using the props that were received. This allows us to make a very generic and reusable Universal component!
We’ll npm install the packages needed to get universal components working. I'll introduce the family of packages that make this possible:
You can preload specific code bundles very easily with react-universal-component. You may know that a particular feature is likely to be loaded, so you can preload it. You still get the benefit of a fast initial render while also having other features loaded very soon after, ready to go.
We’ll use the
Many times while building an AngularJS application you'll need to manipulate data, and it doesn't make sense to do it with a Controller method. Luckily you have Filters, which are particularly well suited for manipulating text within your HTML views. This handy tool uses a simple syntax to create highly reusable functionality for your apps.
In Single Page Apps we're used to fetch the data on event callbacks. That disables the capacity to use the URL to share it to someone else and get to the same state of the app, just like in non Single Page Apps.
This lesson shows you how to use React and React Router to use the URL as the source of truth for your app state.
Sometimes you need to cancel a pending request based on an action performed by the User. In this lesson we’ll see how we can stop an in-flight ajax request by dispatching another action into the store and making use of the Rx operator ‘takeUntil’.
Epics can be unit-tested just like any other function in your application - they have a very specific set of inputs (the action$ stream) and the output is always an Observable. We can subscribe to this output Observable to assert that the actions going back into the Redux are the ones we expect.
Manually creating action items every time we need to dispatch an action eventually accumulates to a very tedious process. In this lesson, we will learn how to abstract out the creation of action items so that we consolidate their creation into a single place. This not only creates efficiencies in how we express code but also reduces code volume while simultaneously increasing stability.
One of the primary advantages of using redux is that reducers are incredibly easy to test. By nature, they have a clearly defined contract of inputs and outputs, and because they are stateless, they require very little instrumentation to test in isolation.
We will start with a few simple tests for the categories reducer and then move on to testing the CRUD functionality within the bookmarks reducer.
In this lesson, we are going to learn how to enable our store to work with more than one reducer in an application.
Currently, we have set up our store to work with the categories reducer exclusively, but this leaves us with a real problem, what if we want to keep track of the currently selected category within our store so that we can access that data somewhere else in the app? It is safe to say that most applications consist of many data models interacting together, and we need a way to accommodate this within the single state tree in our application.
When we initialize our app store, wouldn't it be convenient if we could take all of our reducers and combine them into one big reducer that our store knows how to work with? Well, this is exactly what the combine reducer method does in Redux. It allows us to combine reducers together and then access them as a named property on our application store.
We currently have a category reducer just hanging out here doing nothing because we have been focusing entirely on the categories reducer. We are going to combine the two reducers so that we can use the current category data within our bookmarks component.
Invariably the question that comes up when talking about Redux is how does one handle asynchronous operations in redux. For instance, how do we hand off an operation to redux that requires a remote call to the server? Where exactly does the async part get handled?
Redux has this concept of middleware that allows us to insert custom logic in the space between dispatching an action, and the moment it reaches the reducer. In this lesson, we are going to set up a few async operations and then use redux thunk middleware to make sure that everything makes it into the reducer properly.
The main key to thunk middleware is that it allows us to return a function instead of an action. This function can encapsulate the async operation and dispatches the appropriate action when the operation is completed.
In this lesson, we are going to learn how to map our Angular component directly to our application store using the connect method on ngRedux.
In Angular, it is a common technique to bind a controller property directly to the model so that our controllers remain lightweight and operate more as a pass through mechanism than anything else.
Using the connect method, we can accomplish the same effect by not only binding properties directly to the application store, but also binding our controller to our action creators. This allows us to drastically simplify our controllers as we are able to delete a bunch of local controller methods as they become unnecessary because of our mappings.
In this lesson, we are going to learn how to integrate Redux Devtools into our Angular application.
Redux Devtools is a live-editing time travel environment for Redux. Devtools boasts a list of awesome features but my two favorite ones are that we can inspect every state and action as it happens and we can go back in time by “cancelling” actions.
This is going to be an interesting lesson because, in order for this to work, we are going to need to make something that was written for React work in Angular. For the most part, everything will play side by side with one small trick that we will pull off at the end to force an Angular digest cycle when React manipulates the application store.
In this lesson, we are going are going to apply everything that we have learned by building out our bookmarks component to be powered by Redux. This will help reinforce all the techniques we have covered by seeing them built out in a single, contiguous lesson.
We will walk through the steps necessary to phase out the bookmarks model with a Redux implementation that includes building and integrating the equivalent reducers and action creators to integrate into our application.
One of the biggest mental shifts that developers have to take when embracing redux is shifting from mutable operations to immutable operations. The problem with mutable operations is that they create side effects that involve anything else that is referencing the thing that is being mutated.
With immutable operations within a reducer, a new object is returned for every operation – completely bypassing the possibility that an existing reference is going to be compromised. It is then up to the consumer to decide how they want to get the new data and what to do with it.
In this lesson, we are going to flesh out the CRUD functionality of our bookmarks reducer, doing it first using mutable operations and then refactoring it to use immutable operations.
Up to this point, we have created an effective, yet rudimentary, implementation of Redux by manually creating an application store, reducers and action creators. We have already made significant progress in simplifying state management within our application, but we have in fact only touched the surface of what Redux has to offer.
In this lesson, we are going to introduce ngRedux into our application and let it handle the rest of the heavy lifting as we work through this series. ngRedux is a project that provides angular bindings to redux to streamline integrating it into our application.
In this lesson, we are going to extend our application store with a subscribe method so that we do not have to manually query our application store every time we dispatch an action.
In our categories controller, we are dispatching a GET_CATEGORIES action every time we want to update the categories collection within our application store. For this change to be propagated back into our controller, we need to call store.getState.
Depending on how many times we are calling store.dispatch, this could get very cumbersome. We will extend our application by adding a subscribe method so that state changes are automatically pushed into our controller.
In this lesson, we are going to learn how to build an application store so that we can have a single place to store our application state. Reducers are great for updating state because they are stateless, but they are very bad at preserving state, which is vital when you need to reference state in more than one place.
We will build out a simple application store that will be responsible for keeping track of our categories collection that our categories controller can consume.
Welcome to the series where we are going to learn how to integrate Redux into an existing Angular application.
One of the most challenging aspects of programming is state management. The complexity involved with managing state exponentially increases with each moving piece that we introduce. For every piece of shared, mutable state that we have in our application, there is an opportunity for unintended behavior. For instance, let us say that we have a collection that is shared between two controllers; how do we modify it from one controller with absolute certainty that it isn't going to adversely affect the other?
Redux was initially created for React, but it is in fact, a really solid programming pattern that we can easily apply to our Angular applications. The beauty of Redux is its simplicity in so much that someone could create an implementation of Redux in less than 10 minutes. This is exactly what we will do in the first couple lessons as we build out our reducers, actions and application store by hand before we introduce ng-redux to handle the rest of our abstractions.
We will also learn how to combine reducers, introduce middleware for async operations, map state directly to our actions, test reducers and even hook up Redux devtools. By the end of the series, you will have the tools in your hands to tame state management within your angular application while reducing the overall complexity thanks to the simplicity of Redux.
In this lesson, we are are going to learn how to abstract out state mutations into a reducer. In our current Eggly application, all of the state and business logic for our categories is handled within the categories model. We are going to refactor our code to entirely eliminate the need for our categories model by building out a couple of reducers and seeing how we can interact with them directly.
The key thing to notice as we build out our reducers is that a reducer itself is completely stateless because it receives current state every single time it needs to calculate and return the new state. With a clearly defined contract of inputs and outputs, this makes testing reducers really easy which is one of the huge benefits of using this approach.
In Angular 2, we use observables to push new data to our components. In Angular 1, we occasionally need to notify a component that a collection has changed so that we can perform an operation at the component level.
For example, when we are editing or creating a bookmark, and we navigate to a new category, we are left in this awkward state of an incomplete edit.
We need to be notified when a new category is selected at the bookmark level so that we can reset the current bookmark. Even though we do not have the convenience of an observable to emit state changes to us, we can still spin up an event bus to let us know when we need to hit reset.
Angular exposes key events within a component's lifecycle so that we can apply our own custom logic. In this lesson, we will learn how to leverage component lifecycle hooks to adhere to best practices of keeping our initialization logic out of our constructor.
Traditionally you had to create DOM elements to test a directive but by shifting our focus to components, writing unit tests got a lot easier using $componentController within ngMocks. We can now test our component's controller with an easy to use API that does not require us to spin up any DOM elements to do so. In this lesson, we will see how our ES6 tests are transpiled, learn how to test a component using $componentController and talk about how to simulate lifecycle hooks.
Managing state is one of the hardest things to do in any application. Angular 2 tackles this problem by making it easy to implement a reactive, uni-directional data flow that favor immutable operations. We are moving in the right direction in Angular 1 by moving our state and logic to models but invariably this raises a question. If we are moving to an immutable world, how do you manage mutable operations like forms in Angular? In this lesson, we are going to learn a surprisingly simple technique to isolate state mutations within a component using component lifecycle hooks.
Angular 2 introduces the concept of inputs and outputs as a mechanism for components to communicate. The most significant advantage of this is that we can create presentation components that are void of any imperative logic as they rely entirely on their parent container component. We will learn how to create inputs and outputs in Angular 1 using isolated scope and the component binding syntax.
In Angular, our controllers should be small and focused on the view that it is controlling. We accomplish this by moving as much logic and state as we can into models. Angular 2 introduced observables and async pipes which make it easy to manage state and communicate that directly to our templates.
We can start to point our Angular 1 applications in that direction by binding to our models directly from within our controllers. In this lesson, we will see a simple example of this technique and a slightly more advanced case where we lose the lexical reference to the
Angular 2 leverages new language features in ES6 and TypeScript so that we can organize and express our ideas better. By writing our Angular 1.x application in ES6, we can create a surprising resemblance to an Angular 2 application. To do this, we need to set up Webpack and Gulp to convert our code into something the browser can safely understand. In this lesson, we will learn how to configure Webpack to process our source code and then hook it into Gulp as part of our build system.
In Angular, we want to keep our controllers lightweight and specific to the view that it is controlling. To accomplish this, we are going to refactor our categories collection into a CategoriesModel. A recurring theme in Angular 2 is that everything is "just a class". When we create our controllers and services in an Angular 2 style, they are also "just a class". We will see this in action as we convert our controller almost verbatim into a service.
In this lesson, we are going to talk about dependency injection in an Angular application in ES6. There is a gotcha that I want to point out that most people will run into especially if they have not spent a lot of time using a classical language. We will start with a contrived example and then anchor it back into our application when we modify our CategoriesModel to use the $q service to return a promise.
The simplest version of a component in Angular 2 is nothing more than a container for a template. When we need to introduce imperative logic into our component, we do that via an ES6 class. We accomplish the exact same thing in Angular 1.x by using an ES6 class to serve as a controller for a component. In this lesson, we will examine an Angular 2 component to establish the pattern and then illustrate the similarity as we build out our own controller in ES6.
An Angular 2 cornerstone is component driven architecture and how we divide up our features into self-contained components and then fit them together. In this lesson, we will cover the basic structure of a component in an Angular 2 style as we build one from the ground up. Equally important, we will see how to integrate it into our application by adding it to our root component.