Forem: Tamrat

3 fundamental things I learned about React

Tamrat — Thu, 10 Aug 2017 13:17:22 +0000

I am learning about React and I found a talk given by Pete Hunt as one of the best “birds eye view introduction to React(even though it’s from 2013). The talk helped me really conceptualize why I was actually using React while making my first React app :)

There is an enormous amount of tutorials on React. However, a lot of them only explain the HOW of React and don’t adequately explain the WHY of React. I believe knowing the WHY in anything comes first and over time, becomes much more valuable than the HOW.

Here are some notes I took from the talk:

Short version

Build Components, not templates.
Re-render, don’tÂ mutate.
Virtual DOM is simple andÂ fast.

React

React is a JavaScript library for creating user interfaces.
React renders your UI and responds to events.
Simply put React's basic formula is function(data) = View
A JavaScript function accepts arguments and returns a value. Similarly, a React Component receives data (props) as an argument and returns a UI(view).
Then the entire React application becomes a composition of functions that together makeup the object representation of your UI(View).
JSX is just an abstraction over those functions and it simply transpiles down to a JavaScript representation of a DOM object.

1. Building components, not templates

a. What does separation of concernsÂ actually mean?

Separation of concerns doesn't mean separating technologies (i.e. templates). It means reducing Coupling and increasing Cohesion between the concerns regardless of technology.
Coupling: The degree to which each program module relies on each of the other modules. If you want to implement a feature or fix a bug and you make a change to one module or class, how often do you have to go to other parts of your module or codebase and make changes in order for that feature to work. These sort of cascading changes are symptoms of coupling and that’s what makes software hard to maintain.
Cohesion: The degree to which elements of a module belong together. It is based on the single responsibility principle and basically means grouping related functionality into modules. The litmus test is to ask “does this function make sense? or “Is this function doing a lot of stuff and can you refactor it into other pieces?”

b. A framework cannot know how to separate your concerns forÂ you.

It should only provide powerful and expressive tools for the user to do it correctly. This powerful and expressive tool is a React Component.
React Component = A highly cohesive building block for UIs, loosely coupled with other components.
React uses components to separate our concerns with the full power of JavaScript and not crippled with a templating language.
React Components are reusable, composable and unit testable.

2. Re-render the whole app on every update

This is the key design decision that makes React awesome.
Building UIs is hard because there is so much state. Lots of UI elements, design iteration, crazy environments, mutable DOM, user input, etc.
Data changing over time is the root of all evil. It is really hard to reason about.

Our intellectual powers are rather geared to master static relations and our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program(spread out in text space) and the process (spread out in time) as trivial as possibleâ€Š–â€ŠDijkstra

In short, Dijkstra is saying that it is really hard for us to think of processes over time but it’s fairly straightforward for us to trace the flow of a program.
So we should take processes that go over time and build abstractions that make them look like programs that execute in a single point of time.
It was easier in the 90’s: when data changes just refresh the page.
Now with React when the data changes, React re-renders the entire component. This makes it really easy for us to think about what state our application is in.
That is, React components describe your UI at any point in time, just like a server-rendered app.
Re-rendering on every change makes things simple. Every place data is displayed is guaranteed to be up-to-date without an explicit DOM operationâ€Š–â€Ševerything is declarative.
However, re-rendering on every change is an expensive operation! And that’s why React also comes with a Virtual DOM.

3. VirtualÂ DOM

VirtualÂ DOM makes re-rendering on every change fast.
You can’t just throw out the DOM and rebuild it on each update.
Virtual DOM is built to optimize for performance and memory footprint when performing a re-rendering.
On every update, React builds a new virtual DOM subtree and diffs it with the old one. Then it computes the minimal set of DOM mutations and puts them in a queue and finally batch executes all updates.

Blogging Driven Learning

Tamrat — Mon, 24 Jul 2017 17:16:31 +0000

When I seriously started learning programming about 8 months ago, I had a hard time memorizing important concepts that I was learning. The process went something like this:

Learn about some JavaScript concept. Let's say clousures.

See it used on a tutorial some days later.
Try to recall what closure is but fail.
Google around and discover 4 more slightly different explanations of what clousureÂ is.
Get frustrated, give up on trying to really understand clousure and move on with the rest of the tutorial.

I knew this was not going to be sustainable. It all changed when I watched this course on UdemyÂ (only $10 at the time!). What is so great about the course is that it throughly explains in detail, all the other concepts needed to explain one concept. It felt like reading a good story.

I started writing a blog post to help me memorize the concepts.

The post ended up being 1500 words long! This might not be a lot for regular bloggers, but for me, I hadn't bloggedÂ 1500 words in total before.

For each concept learned, I created my own example/implementation of it. The point was not to fully understand all the concepts, rather it was to document each concept and concretize it in my own terms.

This meant that every time I forget what a concept entailed, I no longer frantically google it. Rather, I comeback to my blog post and acclimate myself again and again. If I have learned something new in between, then I modified the blog post accordingly. The repetition of this process allowed for concepts to sink in my head organically. This way, I no longer solely relied on memory retention.

I've repeated this Blogging Driven Learning methodÂ a few times now and it's been working great!Â

I wrote this to learn about Node JS
I am also currently doing a series on Data structures and Algorithm in Javascript: Lists, Stacks,Â Queues,Â Linked Lists and more coming soon!

So in the end blogging has become a reliableÂ cheat sheet / documentation written for myself. And now my blog is full of unpublished drafts about all kind of topics (programming, meditation, architecture...) that I plan to explain to myself using the same method.

There is of course another dimension to blogging: It's Public! In fact that is the scary part in all of this, specially writing about technical topics. The most important realization that helped me get over this fear is the fact that I'm really blogging for myself. It justÂ so happens that other people can also see what I write.

If other people find what I write useful, great! However, as far as I'm concerned, my blog has an intended grand audience of one person.

p.s. If you are looking for a fronend dev who's always eager to learn ðŸ˜‰, ping me @tamrrat !

Notes on the World Wide Web and the Internet

Tamrat — Thu, 13 Jul 2017 22:46:09 +0000

It dawned on me that while learning to program for the web, I've never taken a step back to actually understand some of the most fundamental concepts of the web. So I decided to fix it...by furiously googling on the internets of course! :) I also took some notes...

The World Wide Web is a magical place where all the interlinked web resources live. Each resource is identifiable by a Uniform Resource Locator (URL) and accessible via the Internet.

Resource - an entity that can be identified, named or addressed in any way whatsoever, on the Web.

The Internet - is a network of interconnected computers that communicate using a host of protocols.

Client Server Model - is one model that dictates how computers interact with each other over the internet. Typically the client initiates the communication with a request for a resource or a service and the server provides a response. The browser is one such client that users use to communicate with a server.

IP (Internet Protocol) - is a unique address that identifies each interconnected computer in the client server model. But before the client and server exchange a request and a response, they need to establish a connection with each other in a process called Three-Way Handshake.

Three-Way Handshake - in simple terms, first the client sends a Synchronize packet to the server. The server then sends a Synchronize Acknowledgment to the client. Finally, the client sends back an Acknowledgment and the process is done. After identifying each other, the client and server can nowÂ open a socket connection between them.

Port number - is a number that identifies the specific program on the computer that is making the request/response. The client and server can now send information back and forth across the socket connection using this Port number.

Packets - the information being sent back and forth is not sent all at once. It is split into small packets of data and sent across the socket from one computer to another.

TCP ( Transmission Control Protocol ) is the protocol that specifies the way in which the splitting of the information into small packets is conducted.

HTTP is the protocol that defines how each individual packet of information transmitted over the socket should be structured.

HTTP also consists of verbs that indicate a type of action to be performed on a specific resource. Most common verbs are the GET, POST, PUT and DELETE verbs.

URL - is simply a web address that points to a specific resource in a network.

To sum it up, when we type in a URL and hit enter on our Internet connected browser (client), we are telling the browser that somewhere in the World Wide Web there exists a resource at this URL address, can you please GET it?

The browser then makes an HTTP request to the specified server. The server then responds with a resource in the form of HTML, which might prompt other requests for images and css. After it receives the response, the browser then proceeds to render the webpage.

Representational State Transfer (REST) - is a set of stylistic architectural principles to guide application development.

Representation - Whenever a server responds with a requested resource, what we get back is not actually the resource object itself. Rather, the server gives us only a representation of the current state(data) of a resource object in a specific format, perhaps JSON. But the response could've also been in an HTML or an XMl format.

In a similar manner when a client makes a request. The request is a representation of the desired state of the resource. The HTTP verb included in the request tells the server the desired action to be applied to change the state of the resource (GET, PUT, DELETE...).

REST is then a set of rules on how a client and a server can transfer the state of a resource via representation.Â When a user interacts with a resource like clicking a link, another request is triggered to transfer the next state of the resource.