Front End - My checklist in learning front end frameworks

Posted on September 12, 2018

After being involved in developing a big SPA I’ve developed a “To-learn” checklist when it comes to component based front end frameworks, which is pretty much all of them nowadays. So far this list has helped me with react, angular, and vue.

Here they are in order:

Directory Structure

So far this has been the most important for me. If I can organize and access files easily through out the project it will make the whole development process easier because trying to figure out relative paths can become an overhead when dealing with thousands of files, at least for me.

Since Typescript doesn’t have a convenient module system out of the box. I need the framework to be able to accommodate barrel files. It has happened before where some versions of angular was not too friendly with barrel files but I think they’ve changed that because I’ve been using a lot of barrel files in an angular project and it’s been working like a charm.

Typescript helps out a lot in this because in tsconfig.json, in the path field I can set a path to a directory and I can access it through out the project without knowing the relative path.

Here’s how it looks

"path": {
  "components": ["src/shared-components"]
}

After setting up the path field, I can access files in shared-compoents anywhere in the project like

import { AwesomeComponent } from "components";

This comes really useful when you have a lot of modules accessing your local shared components directory or any shared local directory for that matter. I wouldn’t know how to do this in Javascript, I probably would need to publish the library to npm.

Parent-Child Component Relationship

This is when the parent and child component communicates. This is another thing that I find important because parent components need to pass information to their child components, and child components need to send messages to their respective parent component.

In react and vue, passing down information to a child component is in the form of props/@Props. In angular it will be through the @Input decorator. They’re pretty similiar when it comes to passing down information but angular is a little bit diffrent when it comes to the child passing it’s information to the parent. In react and vue you’d pass a function/method to the child. In angular, the child emits the event then it’s up to the parent which method to asssign to capture that event.

Using parent-child component communication opens up to reusable components, if your components only rely to props, @Input, or @Props just like a function that only relies on it’s arguments (see also combinators). You can reuse this component in every parent component that supplies that props.

Life Cycle

There are steps on how a component is rendered in these frameworks/library. These steps are important to know when I start fetching data, binding data, re-rendering the component, and if there’s a behavior that needs to happen when the component gets destroyed. These frameworks also offer more granular life cycle hooks, these can be used if the common life cycle hooks can’t handle the use-case.

Routing

Almost every application will have different routes to seperate information, and the framework routing mechanism can help make it easier. Basic routing nowadays are pretty straightforward.

What I need to learn when it comes to routing are:

  • Nested Routes
  • Lazy Routing
  • Nested Lazy Routing
  • Route guards

A page can show different information, and sometimes I need to render some window that can show more than one page of information inside the main page. This is where Nested Routes comes into play.

With big applications, Lazy Routing helps in decreasing Time to Interactive because the application will only load the ui components that are needed at that moment of render, it doesn’t bring in the rest of the components.

Nested Lazy routes become useful when I have nested routes that I don’t want to load if the user doesn’t interactive with them.

Route guards are useful when I want to restrict users to access certain sections of the application depending on their roles/permissions. This comes really useful when it comes to multi-tenant applications.

Transclusion/Multitransclusion

I think this term only gets used in Angular from what I’ve seen so far. This is component composition in react, and it’s called slots in vue. This is how it looks:

react

<SplitPane right={ComponentOne} left={CompoentTwo} />

angular

<split-pane>
  <component-one right></component-one>
  <component-one left></component-one>
</split-pane>

vue

<split-pane>
  <component-one slot="right"></component-one>
  <component-one slot="left"></component-one>
</split-pane>

It’s a way to compose components. This becomes really useful with reusable components. When this is done right, building a complex component can feel like a playing with legos.

State Management

With a rich application comes state and with state comes suffering. Especially if it’s not properly managed. So far the redux implementations have helped me. I’ve used redux for react applications, ngrx for angular, and recently I’ve been learning how to use vuex in a vue application. What I’ve noticed so far is if there’s an atomic store that keeps track of the state and it’s changes, a huge application is easier to manage. My biggest complaint about redux is it’s boilerplate.

Forms

Finally, Forms! From what I’ve seen, forms can be the most stateful component when it comes to editing data because you have that intermediate state that needs to be updated/edited then resubmitted somewhere, and that includes form validation. So I think there’s a lot going on when it comes to forms. When I get a handle of forms in frameworks/libraries I’ll be more comfortable using it.

Final thoughts

There’s definitely more to learn than this list but when I can check off all these items I’ll be comfortable with the framework, and when I go into a project I can hit the ground running.