DEV Community: Aswathprabhu R

What is Reactivity? 🤯

Aswathprabhu R — Sun, 12 Jul 2020 19:48:27 +0000

Reactivity in a framework is a declarative programming model that takes care of keeping the DOM(Document Object Model) in sync with the updates to current state

I know that it's hard to sip, let's get practical so that we solidify our mental models and get a good hold of it!

Let's code up a plain old counter by hand. With the advent of many javascript frameworks and libraries, it is a pretty easy task to accomplish. Will it be the same when developed with plain javascript?

Forget all the frameworks and libraries, Your only tool is javascript now and just get ready for the adventure!

index.html:

Our counter will be rendered into #app.

index.js:

class Counter {

  count = 0;

  handleIncrement = () => {
    this.count++;
  };

  handleDecrement = () => {
    this.count--;
  };

}

I'm defining a class Counter, with a property count that defaults to 0 and two methods handleIncrement, handleDecrement that handles increment and decrement actions respectively. Our current state is the count property. Whenever the state is updated, our DOM should be synced up. It shouldn't be stale.

Since we are dealing with plain JS, we should be creating our increment and decrement buttons by hand right? That's what our next task is!

index.js:


  setUpButton(action) {
    const actionHash = {
      Increment: this.handleIncrement,
      Decrement: this.handleDecrement
    };
    const button = document.createElement("BUTTON");
    button.textContent = action;
    button.onclick = actionHash[action];
    return button;
  }

Our setupButton method ensures that It creates a button and associates the respective onclick handler according to the action passed as an argument. So we are done with the functionality. Not bad till now. Let's get it into DOM. We should be coding up our render method now!

index.js:


  render() {

    const app = document.getElementById("app");
    app.innerHTML = "";
    const count = document.createElement("DIV");
    count.textContent = this.count;
    const elementsToAppend = [
      count,
      this.setUpButton("Increment"),
      this.setUpButton("Decrement")
    ];
    const fragment = document.createDocumentFragment();
    elementsToAppend.forEach(element => {
      fragment.append(element);
    });
    app.appendChild(fragment);

  }

This is more of a straight-forward implementation of render method. DOM should be kept in sync with our state count. So we are clearing up any stale elements that were previously rendered at first by setting innerHTML to an empty string. We are creating a div element that renders our count value. Then we set up both our increment and decrement buttons and finally we append everything to the #app element.

Hurray! we are done soon. Let's check whether it's working.

index.js:

new Counter().render();

Output 🤯

Oops, it didn't work as expected 😱

While checking our code we can find that, once we update our state we've failed to render our app again! That's the cause. Let's fix it 🛠

index.js:


  handleIncrement = () => {
    this.count++;
    this.render();
  };
  handleDecrement = () => {
    this.count--;
    this.render();
  };

Finally 😅

The complete source code can be found here.

OMG! see how imperative our solution is 😓. What if we include a magic layer that takes care of these nitty-gritty things. That is, whenever our current state updates, our app should magically rerender declaratively. That's the way to go, right? What if we add another state in the future and failed to do the same? This solution is less maintainable and not future proof.

To the surprise, the modern javascript frameworks and libraries actually act as the magic layer underhood that takes care of these low-level tasks and makes you more productive by letting you concentrate entirely on the app business logic. The DOM will be in-sync with the state updates and that's a promise given by modern frameworks and libraries.
And also we can't simply rerender the whole app for a single state change. These tools also ensure that they efficiently update the DOM and only re-render the parts that are only necessary.

These tools have their own ways of handling state management.

How does React handle it?

React achieves state tracking via the useState API in functional components.

With useState, now the solution is more maintainable and readable and less error-prone. Future updates can be done seamlessly.

useState function imported from react when invoked, returns an array. It contains two elements, the first one denotes the state variable itself, while the second element references a function that can be invoked to update that particular state variable. You can't simply use this.count++ or this.count-- directly as we do in plain JS. We should only use the respective state updater functions. This solution is more declarative than the previous one that we hand-coded with plain JS.

But what if I say that there is a more elegant way for achieving this?

Ember, a framework for ambitious web applications provides us some great APIs that are more natural-looking and syntactically very declarative. You can be free from using any state updater functions like this.setState(). Just count++ or count-- is enough. This is how we do in javascript right?

Octane edition is the latest update in Ember. This has amazed me with lots of cool new features and a more organized declarative programming model. If I had to pick one out of them, the new Reactivity model earns the medal, to be honest.
Let's see how our counter can be implemented with Ember 🤗

Counter.js:

Counter.hbs:

I personally feel this approach to be more natural. You just tell Ember which properties you wanna keep in the state. Ember automatically tracks that particular property and keeps the DOM in-sync on updates to it. Also, your markup is now split into a separate handlebars file, so that your business logic now becomes less clunky and more readable 🤩

This is a lot for now. Let me know your thoughts regarding our approach in the comments below.

Interested to know more about how @tracked imported from @glimmer/tracking achieves this complex work underhood?

Want to know how @tracked keeps the track of different state properties and triggers rerender based on the updates on them?

Curious to know about their internals?

This is what exactly I'll be covering up in my next post. Can't wait for excitement! Meet you there again folks, bye! 🤟🏻

Breaking down Async/Await 🔥

Aswathprabhu R — Sun, 05 Jan 2020 11:00:15 +0000

Async/Await is one of the amazing inclusions in javascript. It provides a first-class way of writing asynchronous code in a synchronous style. Yes, you heard it right, this pattern allows a developer to write code to be human-readable, not only for machines. Code is not only for machines to execute but also for humans to interpret and develop.

Before digging the syntactic sugar, let's get our hands into some predecessors in asynchronous programming to know why this pattern can truly be a silver bullet in the asynchronous world.

Callbacks

Callbacks were the solution for async programming before promises landed. It was one of the pain parts of javascript at that time considering the code flow and complexity. Yes, it troubled the developer a lot. Inversion of control was one of the main concerns to avoid this pattern of programming.

For example, consider this code chunk

somethirdPartyLibrary.checkout(function doPayment() {
 initiatePayment();
})

Consider, you run an online boot camp where you use a third-party service to handle the checkout process for you. Once the library decides that its time to charge the customers, it invokes the callback(doPayment) to record the payment. Everything is fine if the library invokes the callback once. What if due to some issues on their end, the library invokes the callback multiple times, or doesn't invoke it at all. This causes some of the serious issues and may break the trust of customers.

This is the Inversion of control we discussed above. We are handing control of charging our customers to the library. This is one of the weird patterns to be avoided and it is still in use.

And here comes the feature request from nowhere that our customers should be notified regarding the status of their subscription. Using callbacks we will implement the feature this way.

somethirdPartyLibrary.checkout(function doPayment() {
 initiatePayment(function notifyAboutSuccess() {
     showSuccess();
   }, function notifyAboutFailure() {
     showFailure();
   }
 );
})

This results in multiple nesting of callbacks and is somewhat confusing 😓 , right? Now, if we want to perform an action that should succeed success notification we will nest it as a callback to notifyAboutFailure() and very soon we are into callback hell. Our code flow would be like this then.

The Saviour Promises

Promises paved the way for more human-readable code. Using promises, our scenario can be implemented as,

somethirdPartyLibrary.checkout()
.then(initiatePayment)
.then(showSuccess)
.catch(showFailure)

Here the flow is neat and also the control of charging our customers is with us. Some may have doubts that what if somethirdPartyLibrary.checkout is resolved multiple times will then execute multiple times? No that's not the case, a promise can be resolved or rejected only once. Promises are so far so good, the only concern here is that if some task depends upon a promise to resolve then we would normally wrap all of them in the then event handler right? What can be a magical solution that allows us to write asynchronous code in a synchronous fashion?

Here comes the silver bullet 🎯

Using Async/Await our implementation can be rewritten,

(async function() {
  try {
    await somethirdPartyLibrary.checkout()
    await initiatePayment();
    showSuccess();
  } catch(err) {
    showFailure(err);
  }
})();

This is truly a magic right?

Breaking'em down

This kind of flow is achieved with Generators in javascript. Yes, Async/Await is implemented with the help of generators and promises underhood.

function resumeHandleCheckout() {
    iterator.next();
}

function* handleCheckout() {
    yield someThirdPartyLibrary.checkout();
    yield initiatePayment();
    showSuccess();
}

let iterator = handleCheckout();

let promiseFromLibrary = iterator.next();


promiseFromLibrary
.then(resumeHandleCheckout)
.then(resumeHandleCheckout)
.catch(showFailure);

Can you get the underhood mechanism of Async/Await? It handles all the complexity and provides us a syntactic sugar.

This is truly a deal-breaker as it allows the developer to write async code in synchronous style and now more human-readable one. Feel free to share this post with your colleagues as well.

The Mysterious 'Owl' (+)

Aswathprabhu R — Thu, 26 Sep 2019 16:40:03 +0000

Consider a scenario, where you're asked to design a Stack layout, something similar to the below one.

Normally as a WEB DEVELOPER 😅 we will try this,

<style>
  .stack {
    background-color: yellow;
  }
  .stack > div {
    margin-bottom: 40px;
  }
</style>

We will wrap the three text divs with a common div and apply margin-bottom to all its' children. As of now we will be happy with our implementation, thinking how great we are 😅 that the STACK layout is done in a matter of minutes.

However, this will be our output 😩

If you closely see the image, you will notice the third text div also has the margin-bottom style applied on it, which we don't want to happen.

We will try to fix the breakage by doing something similar to this,

<style>
 .stack > div:last-child {
  margin-bottom: 0px;
}
</style>

We will reach our destination, but the path we took... isn't it ugly? 😷

While thinking of other possibilities, I came across (* + *), a construct known as the Owl and its' powers. But the only thing to note is that the 🦉 is little mysterious!. No worries though, let's clear up the mystery behind and unveil its' greatest powers down here...

The 'Owl' construct selects 'any HTML element that is next to or follows(sibling) any other HTML element' booyah 😅

Come lets' smash out the theory, get hands-on with the 🦉

Consider the same snippet updated with,

<style>
  .stack {
    background-color: yellow;
  }
  .stack > *+* {
    margin-top: 1.5em;
  }
</style>

Boom 💥 that's it! This is much simple compared to our old prototypes.

Now the path we took was very clear and really beautiful 😍,

Now lets' dig on to check out what it does underhood 🔍

Digging the snippet we come to know that the Owl construct selects the 2nd and 3rd child and applies margin-top: 1.5em respectively as defined. It doesn't select the first child because, it is an immediate successor of the parent and doesn't have any previous siblings(general behaviour of '+' selector).

Now, I doubted the layout in case of nested HTML elements, an evil thought though 👽, something more specifically like 👇

<div class="stack">
  <div>
    ...
    <div class="inner-div">
      <div>
        ...
      </div>
      <div>
        ... 
      </div>
    </div>
   ...
 </div>
  <div>
    ... 
  </div>
  <div>
    ...
  </div>
</div>

Using our existing style definitions, The inner divs have no margins. The layout obtained is 👇

Oops what to do now, scratched my head a lil' bit and just removed the Child combinator preceding our Owl construct.

<style>
  .stack {
    background-color: yellow;
  }
  .stack *+* {
    margin-top: 1.5em;
  }
</style>

The output obtained is 🎉

So, what the previous snippet does is that, it applies the 'Owl' construct recursively to all descendants not limiting only to the direct children of parent div element.

Hope, you guys figured out the Owl construct with this post. Thanks for being patient till the end fellas! 😆

React Portals are lit 🔥

Aswathprabhu R — Sun, 28 Jul 2019 15:37:59 +0000

Recently I was introduced to Reacts' createPortal API, which was nothing short of amazing.

Let me share my experiences with it!

Being a professional Ember developer, my love towards React has never faded away. React with its' component oriented architecture boosts productivity, ensures stable code and is backed up with strong community.

I don't wanna bore you, with this sort of things that you(probably many Web devs) hear in routine.

I think, Its' time to get our hands dirty with Portals 🔥

'Portals provide a first-class way to render children into a DOM node that exists outside the DOM hierarchy of the parent component'

Generally, not everyone in the world can understand the definition in the official docs in a single glance!, atleast NOT ME! (jus kidding, Reacts' docs on Portals is more beginner friendly peeps, go check it out)

So i decided to have a practical approach with it:

As stated in the definition, Portals provide a way to render children of a react component somewhere else in the DOM, not in the same hierarchy!

As soon i realised it, i was ended up with nothing but questions.

OMG what about the event bubbling? and many...

Being a profressional ember developer, i have used Ember Wormhole, it is an addon probably does the similar work of Portals in Ember.

I kept digging more about Portals. One thing i explored is its' use-case in Modal Dialogs.

I built a modal component with bootstrap(overriding some of bootstrap styles) in react similar to this 👇

//Modal.js
import React from "react";
import ReactDOM from "react-dom";
export default class Modal extends React.Component {
  onClose = e => {
    this.props.onClose && this.props.onClose(e);
  };
  render() {
    let modal = (<div
      class="modal fade"
      id="exampleModalCenter"
    >
      <div class="modal-dialog" role="document">
        <div class="modal-content">
          <div class="modal-header">
            <h5 class="modal-title" id="exampleModalLongTitle">
              Modal title
            </h5>
            <button
              type="button"
              class="close"
            >
              <span aria-hidden="true">&times;</span>
            </button>
          </div>
          <div class="modal-body">...</div>
          <div class="modal-footer">
            <button
              type="button"
              class="btn btn-secondary"
            >
              Close
            </button>
            <button type="button" class="btn btn-primary">
              Save changes
            </button>
          </div>
        </div>
      </div>
    </div>
    );
    return (modal);
  }
}

I rendered it as a child to App 👇

//App.js    
import React from "react";
import Modal from "./Modal-Compo";

export default class App extends React.Component {
  onClose = e => {
    this.props.onClose && this.props.onClose(e);
  };

  render() {
    let alignCenter = {
      display: "flex",
      alignItems: "center",
      justifyCenter: "center",
      height: "200px",
      overflow: "hidden",
      width: "50%",
      margin: "auto",
      marginTop: "10%"
    };
    return (
    <div style={alignCenter}>
      <p style={{ height: "100%", margin: "0" }}>
        //some random 100 lines
      </p>
      <Modal onClose={this.onClose}/>
    </div>
  )
 }
}

Atlast rendered the App component in the root element 👇

//Index.js
import React from "react";
import ReactDOM from "react-dom";
import "bootstrap/dist/css/bootstrap.min.css";
import "jquery/dist/jquery.min.js";
import "bootstrap/dist/js/bootstrap.min.js";
import App from "./components/App";
import "./styles.css";

function WhatAreModals() {
  return (
    <div style={{ height: "100vh" }} className="App">
      <App />
      <button
        type="button"
        className="btn btn-primary"
        data-toggle="modal"
        data-target="#exampleModalCenter"
      >
        Launch demo modal
      </button>
    </div>
  );
}

const rootElement = document.getElementById("root");
ReactDOM.render(<WhatAreModals />, rootElement);

Finally my prototype was ready 😄

When i clicked the Launch demo modal CTA, this happened (oopsy) 😕

The culprit is the App component styled 'overflow:hidden', as in our case the Modal component is rendered as a child of App whose overflow is hidden, our Modal never shows up 😩

Here is where the life saver Portal comes in 🔥

I just made a tweak in my Modal component and the index.html(created another root element for Modal to be rendered)

//index.html
<div id="root"></div>
<div id="modal-root"></div>

Rendered Modal in Portal, changed return statement by implementing createPortal

//Modal.js
ReactDOM.createPortal(modal, document.getElementById("modal-root"));

It worked seamlessly,

The problem was solved by breaking the Modal component out of the container, out of the hierarchy.

But suddenly i got into a confusion, as the hierarchy is broken i doubted whether event bubbling will occur? (I think, Many will question this!).

I went on digging deeper 😁

Native DOM Snapshot:

React DOM:

Finally, i was satisfied seeing this, probably many would be 😌
From the snapshots, we come to know that the hierarchy is unaltered in Reacts' Virtual DOM, so event bubbling will happen with ease.

Portals can be widely used when a parent component has an overflow: hidden or z-index style, but you need the child to visually “break out” of its container. For example, dialogs, hovercards, and tooltips.

I feel this post would've satisfied you on Reacts' createPortal API, if yes, feel free to share this with your colleague web devs as well.

DEV Community: Aswathprabhu R

What is Reactivity? 🤯

Breaking down Async/Await 🔥

The Mysterious 'Owl' (*+*)

React Portals are lit 🔥

The Mysterious 'Owl' (+)