Forem: Alireza Tajadod

Forays into react

Alireza Tajadod — Wed, 20 Jan 2021 14:27:02 +0000

Over the past few weeks, I have had to work with react for the first time in a professional capacity. Having gone through the usual 1) just start coding 2) ok this doesn’t work 3) let me actually read some documents process on every new feature, I have finally arrived at a relatively comfortable place with the framework. What follows is my high level understanding of the react framework. This blog is a conceptual overview of the react framework and the focus on react syntax is minimal.

React uses component driven development. In traditional web development, you think about your app in pages. In react however, the atom (building block) of your app is components. Each component is an isolated independent and reusable piece of the application. The components render separately and have their own lifecycle. This dance of when a component re-renders and what happens on that render is the fundamental theorem of react.

Component Hierarchy:

The first challenge of any component driven development framework, react being one of many, is to identify said components. The challenge here, and for good programming design in general, is to make these components independent and isolated and by extension reusable. One technique for components, just like object or functions, is to make these components have one and only one responsibility. Take the below user interface for example:

There are at least five components here :

TO-DO screen Component: The app. Its job is to be an umbrella for what all the other components are going to do. Useless but necessary, like a product manager.
Header component : The TO-DO list heading.
Input bar component: The add new task piece of the UI.
Listing component: The bigger box of listings under. The listing component is to the TO-DO list items, what the TO-DO screen component is to the entire app.
List row component: Each individual TO-DO item.

The hierarchy would then be :

TO-DO screen
- Header
- Input bar
- Listing
  - List row

For this simple TO-DO above, this may seem like over modularizing and that’s because it is. However, as the application grows, you start reaping the benefits of the design. Immediately for example, your second screen will be able to use the same header component and give your app a consistent feel. If you decide to categorize the listings (into work, school, home) for example, you only need to find the right wrapper for the existing listing components.

Rendering:

In order for the UI to display your components, they need to render. The react magic is the React Dom. React DOM sits between your code and the browse DOM. The browser DOM is what is actually rendered onto the page and displayed to the user. Components are react objects and importantly cheap to create. React Dom takes these objects and updates the browser DOM for you. There are two advantages to this. Firstly, your browser DOM is updated efficiently. React takes care to ensure that the browser DOM is updated as necessary and only if necessary. Secondly, you get to use the power of javascript and react libraries. The react DOM can render a lot more than the browser DOM. Importantly, React, allows the intermingling of rendering logic with UI logic. For example, when a user adds an item in the input bar component, the same react element that handles how the input bar is displayed, will also handle what happens when the add button is clicked.

JSX

JSX places the mark up (HTML) language inside the javascript. JSX is not required by react, however, it allows you to literally put the rendering logic (mark up) and UI logic (javascript) in one place. The isolation then moves from mark up and UI logic (separate HTML and JS files) to components. In your component, in one place, you can develop and see everything that is going with the header tag below.

function formatName(user) {
  return user.firstName + ' ' + user.lastName;
}
getGreeting(user) {
  if (user) {
    return <h1>Hello, {formatName(user)}!</h1>;  }
  return <h1>Hello, Stranger.</h1>;}

Props

Secondly, react allows you to pass props (arguments) from one component to another. For example, if we wanted to limit our list to 5 items, we could set this as a variable in the TO-DO screen component. The TO-DO screen could then pass this prop to the input bar and listing to ensure that the former does not accept more than 5 inputs or the latter does not display more than 5. Props are passed from a parent component such as listing to its child, the list row. A component will have access to the prop during its life. Unfortunately, components don’t live too long, forgetting all about what you just told them as soon as literally anything happens.

Lifecycle:

Because the react DOM is cheap to create, react elements are immutable. That is, you can’t update your react elements. The only way to make changes, is to re-render the entire element. Importantly, react does not do this on the browser DOM. React will only render what needs to be changed on the browser DOM! Working with the react DOM, you gets the benefit of thinking in isolated, cheap and always recycling components, all the while maintaining a high level of efficiency on the browser DOM. UI elements are always changing. The very first letter the user types in the input bar, changes the UI of the input bar. Subsequently, the UI of the TO-DO screen has now also changed. Once the user clicks ADD, all components in the component hierarchy above will change. Each component here has a life cycle. Each cycle in the life of component, is one unchangeable react element with its own props. All the different forms a react component takes, forms its life cycle. Once a react component is mounted (rendered to the browser DOM), it is out of your control. However, before it's reincarnation, you get to play God using hooks. Traditionally, this intervention was done using states and lifecycle methods. More recently, in a functional turn, state hooks and effect hooks and other hooks are used to accomplish the same goals.

State Hooks:

React component (read javascript functions) work with two groups of variables, dynamic and static. Static variables stay the same throughout all the reincarnations of the component. For example, one could define a variable as:

 Header = <h1> TO-DO LIST </h1>

On every render, the header will stay the same. States on the other hand, are what defines each render of the component. For example, all the list rows in our TO-DO list, have the same styling and look. What changes for each row, is the text. For example, the first row is our TO-DO listing row example component has a state of :

 State =  {text: Vanilla Javascript, checked: True}
 
While the last one is:

 State =  {text: Node.js , checked: False}

Consequently, any time the state of a component changes, it will be re-rendered. Unfortunately, the component is destroyed completely on this re-render and does not remember its state. This remembering then must be done somewhere outside the component. One option is to update the state of the parent component, which not being destroyed, will remember the state and pass it back to the component as a prop once it is ready to be mounted again. Another option is to use a storage. A storage, which may itself be a component, will remember the state for all other components and will be used to store/retrieve the states. States are updated via the useState hook.

Effect Hook:

Where states are the variables in a component, effects are the methods. An effect hook runs every time the component renders. Some effects do not return anything. For example, you may want to update the local storage. If you want to keep track of the number of tasks in the listing container, you can set up an effect on each listing row. Once added to the browser DOM, the row will update the number of tasks in the local storage using the hook. The row itself is unchanged, the new number may trigger a state change and re-render somewhere else in your react DOM. Another examples of these effects are calls to external APIs. Other hook effects are used to perform a specific action on the deletion of the component. These effect hooks return the relevant functionality. For example, your ToDo list item maybe synced with google calendar. You can then use an effect hook to call the calendar API to remove the corresponding event once your entry is deleted.

There are other hooks that can help manage the lifecycle of a component. State and Effect hooks can handle most of the cases for a react application. In a nutshell, you create a component with specified states and effects. On a state change, the component renders again relying on the local storage or its parent to remember the state change. Once the component has been rendered to the browser, your effects take place. These effects may themselves cause your component to render again or wait around for a render to be triggered before taking effect. On and on, the react components are created and deleted but never updated.

The Ansible Framework

Alireza Tajadod — Tue, 19 Jan 2021 16:12:43 +0000

Software applications, once developed locally, need to be made available for public use. In order for this to happen, they need to be deployed to a server. This server, which maybe physical or a cloud server, needs to be provisioned for your application. Ansible is used to configures a server for your use. If you are running a python web application for example, the server needs to have python installed, similar to how you would install python on your local computer (read server). Of course, for a web application to run successfully in production, it needs far more than just Python. You need to deploy your code and supporting libraries, configure the server to listen securely for incoming requests to your application and balance these calls and more. What is worse, often more than one application is deployed on one server and one application is deployed to multiple server. Provisioning these servers for your applications manually is as painful as it sounds. This is where Ansible comes in.

Ansible, is a python based, open source, IT automation framework. Ansible enables you to provision your server via reusable and maintainable playbooks as well as providing a rich ecosystem to minimize the effort required for developing said playbooks . An Ansible playbook is a recipe of steps to be executed on a server. I will delve deeper into these playbooks in the next section. These playbook are at the core of the Ansible framework. Just as a web framework enables you to focus on your domain logic, Ansible enables you to focus on your specific server configurartions

The Ansible Framework

Ansible works with a control node and managed nodes. There is only one control node. This node is responsible for provisioning all your other nodes. The control node is your command center, managing all other nodes. These other nodes, you guessed it, are the managed nodes. You may have only one or multiple managed nodes. For our purposes, you can think of each node as a server. To keep track of these managed nodes, Ansible uses a host file, known as the Inventory. The control node, provisions your managed nods as found in the inventory based on your playbooks.

The Playbook

An Ansible playbook is a set of tasks Tasks. These playbooks come together to create a Role. Multiple roles typically come together to provision a managed node.

tasks, playbooks and roles

A task, is a command to executed on a node. An Ansible task can install a software, pull your code from git or any other command you would typically run on your server. A task is compromised of a name as well as the relevant command.

- name: Copy file
  copy:
    src: /src/myfiles/foo.conf
    dest: /etc/foo.conf

The task above, named Copy file, copies foo.conf from your control node’s src directory into the managed node’s etc directory.

An Ansible task then, is the atom your Ansible project. Put together, a number of tasks compromise a playbook. A playbook should hold all similar tasks. All the files you need to move into a server for example, should be handled in an appropriately named playbook as a set of tasks.
Finally, a set of playbooks form a role. A role is a set of playbooks you want to group together for whatever reason. All the playbooks required to provision a node for your python app for example, could come together to form a role named after your app.

roles/
    Myapp/               # this hierarchy represents a "role"
        playbooks/            
            filestuff.yml     # this hierarchy represents a “playbook”, “tasks” are found inside this playbook.
            pythonstuff.yml    
            secuitystuff.yml     
            ...

Templates and Variables

As more and more responsibilities are given to your control node, in form of more applications or bigger application, you may need to parametrize your tasks. Ansible has a concept of templates and variables. Templates are used at a role level, helping avoid duplicity in the playbooks for the role. Once this variable is set in the appropriate template, your playbook can refer to it by its given name. As with any variable, the template avoids duplicity as well as provide ease of change.

roles/
    Myapp/               # this hierarchy represents a "role"
        playbooks/            
            filestuff.yml     # this hierarchy represents a “playbook”, “tasks” are found inside this playbook.
            pythonstuff.yml    
            secuitystuff.yml     
            ... 
        templates/        #  <-- files for use with the template resource
            pythonstuff.conf.j2   #  <------- templates end in .j2

Certain variables are relevant for all your managed nodes. For example, the name of your organization or an external partner’s API stay consistent on all your servers. These variables are commonly called group_vars. This name is due to the fact that you can speficy a group for an Ansible task which would then correspond to a group variable. These groupings go beyond a specific role and are scoped across all your nods.

group_vars/
   group1.yml             # here we assign variables to particular groups
roles/
    Myapp/               # this hierarchy represents a "role"
        playbooks/            
            filestuff.yml     # this hierarchy represents a “playbook”, “tasks” are found inside this playbook.
            pythonstuff.yml    
            secuitystuff.yml     
            ... 
        templates/        #  <-- files for use with the template resource
            pythonstuff.conf.j2   #  <------- templates end in .j2

The Ansible Modules

Ansible playbooks and templates provide reusability and maintainability for your configurations. The modules provide the functionality. At the core of an Ansible playbook is a task, each task is compromised of a command. Above we saw an example of these commands in “COPY”. As you have may have already noticed, nothing in your tasks defines what a COPY is or what it does. COPY, as well as hundreds of other commands, are part of Ansible modules. Ansible modules are classified into more than a dozen categories, amongst which are cloud, system, database and storage to name a few. These module for example includes commands such as :

            - ec2_snapshot (for AWS)
            - digitalocean (for digital ocean)
            - docker-compose (for composing containers)
            - timezone (setting system timezone)
        and many more.

Listed in each of these modules are dozens of commands, where each is used like a function taking in different parameters and performing different functions. If there’s something you need to do, chances are, there is already an Ansible task for it. Taking COPY again as an example, the parameters include.

-          src -> a path string 
-          dest -> a path string
  Which are required as well as other parameters such as 
-         owner -> a string 
-          group -> a string
-          mode -> a string of permissions either in numbers or letters as typically done with chmod.

All together, there are thousands of these module commands, No matter what it is that you’re doing, chances are, Ansible already has a task for your use. To become proficient with Ansible, you need to become familiar and comfortable with using these tasks. Ansible does allow users to create their own modules and expand on the existing list of commands, However, if you find yourself relying on custom modules and commands, chances are you are not using Ansible correctly.