DEV Community: Tamb

Getting Weird: "Hooks" in React Class Components

Tamb — Sun, 21 Apr 2024 03:34:44 +0000

Before we begin. I know: Class Components are toast. They're dead and they ain't coming back. I'm just messing around in this post... so let's get weird.

We're going to create a contrived example of two components that will fetch the same data. The "hook" created will be a fetch call that exposes data to state.

Here's the Codesandbox: click me!

The "Hook"

export async function useTodos() {
  this.setState({
    fetching: true,
  });

  const resp = await fetch("https://jsonplaceholder.typicode.com/todos");
  const data = await resp.json();
  this.setState({
    todos: data,
    todoCount: data.length,
  });
}

The above code simply fetches data and assigns it to state. this is nebulous at this point. It will refer to the housing function. But we'll assign the context of this in the next code snippet.

Component 1

import React from "react";
import { useTodos } from "./hooks";

export default class TodoCounter extends React.Component {
  constructor(props) {
    super(props);
  }

  UNSAFE_componentWillMount(): void {
    useTodos.call(this);
  }

  render() {
    return (
      <div>
        <p>Todos: {this.state?.todoCount}</p>
      </div>
    );
  }
}

Here we are assigning the value of this in the hook by using call in the component.

Note how you don't even have to define state here to access the hook data.

And (like hooks) you can use this in other components

import React from "react";
import { useTodos } from "./hooks";

export default class TodoList extends React.Component {
  constructor(props) {
    super(props);
  }

  UNSAFE_componentWillMount(): void {
    useTodos.call(this);
  }

  render() {
    return (
      <ol>
        {this.state.todos?.map((todo, i) => {
          return <li key={i}>{todo.title}</li>;
        })}
      </ol>
    );
  }
}

So yeah, it's super stupid. But you could use "hooks" all along with class components. We got weird.

Side note: I hate functional components. I think the lifecycle methods of class components map more closely to how DOM and web component lifecycles work. But React is ditching all of that for their functional approach. That's fine. But I'm just switching over to StencilJS instead. I prefer my OOP.

What have you Lost and Gained with Front-end Complexity?

Tamb — Thu, 22 Apr 2021 14:48:15 +0000

In 2021 front-end software is almost ridiculously advanced.

You've probably read about the history of JS and how brutal cross-browser compatibility used to be. The jQuery days were actually quite exciting and in many ways they still are.

If you think about jQuery for one second, it's a massive compatibility layer wrapped up in one global object $. That's incredible.

jQuery actually hindered a lot of developers because those folks learned jQuery first and JS second. Today, a lot of developers now are falling into learning JSX first and JS second. While there's nothing terribly wrong with this approach (JSX still requires JS knowledge) there is a hidden "jQuery-esque" magic behind the build processes used to convert JSX in pure JS.

Most developers cringe at the thought of going back to ASP or JSP HTML templates and writing pure vanilla JS and CSS.

But it's actually essential to know these things.

While no one can ever fully "know" HTML, CSS, and JS (this is according to the "Essential Difficulties" in software design, it's important to at least have an idea of what you don't "know".

I'm not going to write a whole article on the inner workings of webpack or the differences between OOP and Prototypical Programming. I want to hear from you folks about what you've lost and gained in the complexity of front-end build processes and software advancements.

Are React Hooks Actually Worth Using?

Tamb — Tue, 16 Feb 2021 14:20:56 +0000

Full disclosure, I am not fan of Hooks. They seem to abstract away a part of Component Lifecycles that never needed to be abstracted. Checkout out this article: https://codewithghazi.com/componentwillunmount-with-react-hooks/

Instead of componentDidMount and componentWillUnmount, Hooks makes us use the cryptic useEffect:

useEffect(() => { 
   document.addEventListener('click', handleClick);

   return function cleanup () {
     document.removeEventListener('click', handleClick);
   }
}, [])

I understand using Hooks for simple functional components that require some small uses of state. But once we get into lifecycle methods and about half a dozen state fields, I find that hooks actually get in the way.

I really like code that explains what it does. I prefer setNameOnClick as opposed to handleClick (unless I'm making a reusable Component).

I like state that is easily identifiable. this.state.userName is clearer to me than userName.

Overall, Hooks to me seem like they make code more "code-y" and I know I want a coworker to be able to understand my work ASAP.

Thoughts?

What JS Libraries Have You Made?

Tamb — Tue, 19 May 2020 15:43:30 +0000

What libraries are you proud of?
What did they seek to accomplish?
How successful do you think they are?
What did you learn?

Share the repository links below:

Bootstrap Native. Bootstrap WITHOUT jQuery Today

Tamb — Mon, 11 May 2020 14:47:13 +0000

We get it. We all get it. Bootstrap JavaScript is heavy because it requires jQuery. You are right. So here are the bare facts about an alternative I found a while ago:

Bootstrap.Native: https://github.com/thednp/bootstrap.native

Size

Bootstrap v4

Bootstrap v4: 60+ kb
jQuery-slim v3: 60+ kb
popperjs: 20+ kb

Total: 140+ kb

Bootstrap.Native

Bootstrap.Native: 20+ kb

Total: 20+ kb

Dependencies

Bootstrap v4:

popperJS
jQuery-slim

Bootstrap.Native
NONE

What about Bootstrap v5? Isn't that Vanilla?

Yes. It will be. But as of writing this, a stable version of that seems fairly far off (sometime later this year??). Also, sometimes it's good to support a smaller library that works incredibly well. Bootstrap.Native has 1.6k stars on GitHub and 8k download a week on npm. It's not feeble and it still leverages the CSS from Twitter Bootstrap.

Conclusion

Give Bootstrap.Native a serious try. Build a proof of concept with it and with Twitter Bootstrap. I guarantee you will find that Bootstrap.Native loads faster, performs smoother, and is just as easy to implement. I use it. It's honestly great. The documentation is lacking at the moment but you can just read the original Bootstrap v4 docs.

Dear WHATWG, fix datalist

Tamb — Tue, 05 May 2020 14:13:11 +0000

Dear WHATWG,

For as long as moonlight has kissed the darkened night sky, front-end web developers have been creating hacky and cumbersome "typeaheads". Some people know these components as "autocompletes". Most of us know them as PITA (see Urban Dictionary).

There has been a semi-perfect solution in native HTML that has existed for millenia (Internet Explorer 10): the datalist element.

datalist is such a noble and proud element. It has stuck around through years of abandonment and abuse, watching div and JS take all the credit for functionality it has provided since its conception.

More recently, web components and their fill-in libraries have tried to make commonplace what datalist was meant for all along: being a native typeahead.

But datalist has weak spots that the partnership of div and JS have exploited again and again.

`datalist` weaknesses:

options cannot be styled
options cannot take additional HTML
options cannot be augmented with JavaScript
It provides no event API for filtering a list

Why the WHATWG has neglected datalist? I honestly don't know.
It gets a small blurb in their docs:
https://html.spec.whatwg.org/multipage/form-elements.html#the-datalist-element

And for the W3C it appears in one line under the list attribute on their site:
https://www.w3.org/wiki/HTML/Elements/input/text

So WHATWG, in the age of evergreen browsers, what the actual F are you doing??! Fix the above weaknesses. Give developers a native typeahead instead of forcing us to adopt newer tech like web components and shadow DOM.

Sincerely,

Many, many front-end developers

React vs Preact vs Inferno

Tamb — Wed, 29 Apr 2020 15:41:19 +0000

Obviously React has changed the landscape of front-end development. In the Virtual DOM Kennel, it's the "Big Dog". And it's been gettin' it on. In fact, the library has spawned two similar libraries that (when it comes to Web Development) give React a run for its money.

I'm talking about Preact and Inferno. We're gonna go over the pros and cons of both in comparison to React.

Preact

Preact is pretty darn popular. It has over 26k stars on Github and 1/4 million downloads per week on NPM. So this puppy is barking.
npm: https://www.npmjs.com/package/preact
Github: https://github.com/preactjs/preacthttps://github.com/preactjs/preact

It differs from React in a few ways:

There is no synthetic event system. React ships its own (very heavy) Synthetic Event system that offers a host of benefits but comes with a larger size and slower performance. Preact uses native addEventListener so it trusts/uses the DOMs API to a performance and size benefit.
Preact doesn't push JSX as it's client-side templating tool. In fact, the original author of Preact offers his package htm as an alternative. One of the benefits of this is difference is you can use regular old HTML attributes like class instead of className.
An added feature in Preact is that its Component.render method signature has state and props as parameters, so you can access them easier within the JSX or htm.

Component.render({props}, {state});

Pros:

Preact is a lot faster and lighter than React. And it aims to be "mostly" compatible with React.
To have near 100% compatibility Preact offers an additional package: preact-compat.
Preact is compatible and even encourages using htm over JSX so you can unlock regular HTML attributes.
Preact is popular. This means that it's gonna have better support, a larger ecosystem and a quicker fixes.
It offers its own Server Side Rendering, routing, and other popular add-ons.

Cons:

At the time of writing, Hooks are in a separate preact package: preact/hooks. (Though some people may see this a pro)
At the time of writing, Preact only has experimental support for Lazy and Suspense components.
Preact is kind of shoe-horned into a "React clone" category. A lot of development on the library will be to mimic React and not to innovate in its own way.
If you need a React component or package you have to use an additional library. preact/compat makes your project larger and slower but is the only way to bridge the gap between React-based npm packages and Preact.

Inferno

Inferno is a React-eque component library. It has over 14k stars on Github and about 9k downloads per week on npm.
npm: https://www.npmjs.com/package/inferno
Github: https://github.com/infernojs/inferno

Inferno is different from React in the following ways:

It only offers a partial Synthetic Events system. So only certain events are synthesized. This is for performance reasons.
It is built explicitly for the DOM.
It has lifecycle methods on functional components
Inferno setState is synchronous by default and becomes async when chained (it will batch update for performance)

Pros:

It's lightweight (but not as light as Preact)
It really is "insanely fast". Some of the demonstrations will actually blow you away and it even offer internal objects for optimization that will really crank up the speed.
It doesn't aim to mimic React entirely. In fact there are some difference (lifecycle methods on functional components) that truly set it apart from React
Inferno styles are set with regular old CSS property. There's no need to write the property as backgroundColor. You can use background-color.
It offers its own Server Side Rendering, routing, and other popular add-ons.

Cons:

It has a MUCH smaller community. Support is slower and ecosystem is a lot smaller. Expect a longer wait time (or contribute yourself) to get 3rd party libraries and components.
There is no Lazy, Suspense, Memo, or Hooks support. At the time of writing these features are being considered, but my money is on library remaining small.
Since setState is synchronous you will experience differences from React. There's no real way around this.
If you need a React component or package you have to use an additional library. inferno/compat makes your project larger and slower but is the only way to bridge the gap between React-based npm packages and Inferno.

Conclusion

I've used all three libraries. The real benefit of React is how easily it can port to React Native and its support. In terms of performance, only really really heavy DOM manipulation will reveal the gains of Inferno or Preact over React.
This last point is spicy: I don't like hooks. I find them to be a little sloppy and to introduce less uniform standards. For this reason I really like Inferno's support for lifecycle methods on functional components.

In the end, React is still the top dog. But Preact is pretty close behind. The added benefit a larger Preact ecosystem and community makes me prefer Preact over Inferno. I would definitely recommend giving Preact a spin (even if that means you simply add the preact/compat compatibility layer).

Resources:

Here are the sites for each library:

React: https://reactjs.org/
Preact: https://preactjs.com/
Inferno: https://infernojs.org/

Modern Front-end with Older Tech

Tamb — Thu, 23 Jan 2020 21:39:20 +0000

If you just want to see the code:

Here's our finished project: https://codesandbox.io/s/component-example-9796w
Here's the project with my very lightweight library (note the fewer lines): https://codesandbox.io/s/domponent-example-ij1zs

Hey, so I'm a Senior Front-end Developer. I've built performant web UI Components for enterprise-level apps and multi-national companies with AngularJS, React, Vue, jQuery Plugins, and Vanilla JS.
They all have their pluses. Let's go over them quickly:

AngularJS, you can just augment your HTML and build full-fledged complex UIs.
jQuery Plugins, you can just add some classes and attributes to HTML and the plugins will do the rest.
React, the entire app is component based, easy to read, and trivial to reuse.
Vue, you can implement an AngularJS-type solution with an entirely component-driven approach.
Vanilla JS, you don't have pull in any libraries and you can choose whatever lightweight solution you want.

For each approach you can implement UI as a function of state. For some (Vue and React) it's easier done with use of Virtual DOM (look it up if you need. It's super cool).

However, what if you're stuck with older tech? What if you're working with Razor or Pug or Thymeleaf? And additionally, you're not using REST APIs? You have some advantages (SSR by default, SEO-friendly), but you have a TON of drawbacks (lack of Virtual DOM, ergo difficult/verbose rerenders).

With classic front-end web development you lack simplified component state, component lifecycles, scoped models, granular control over model changes. These are all complex to implement and a built-in part of React, Vue, Knockout, Angular, etc.

But with some build tools (webpack, parcel, rollup, grunt, gulp) and some incredibly battle-tested template languages (Thymeleaf, Pug, Razor) you can build UI Components with incredible ease.

Here's how I do it with my older tech stack:

The directory structure

FrontEnd
|
|___components
         |
         |__MyComponent
         |        |
         |        |___MyComponent.pug/.html/.cshtml
         |        |___MyComponent.scss
         |        |___MyComponent.js
         |
         |__MyOtherComponent
                  |
                  |___MyOtherComponent.pug/.html/.cshtml
                  |___MyOtherComponent.scss
                  |___MyOtherComponent.js

Let's run through this.

In a React app, you would have 1 less file. You might even have two less files.
You'd remove the html and possibly the scss. You'd have your HTML as part of a JSX file. You may even have CSS in JS. So it might be a single file component. This is similar to a .vue file.

We're just actually breaking it out here. Screw 1 file, let's go classic and have 3. Logic in JS, Structure in HTML, Look in SCSS. Now, each file:

HTML

Let's make a simple Counter. It's going to show the count and offer and increment and decrement option

<div>
  <p>Your Count: 
   <span>0</span>
  </p>
  <button type="button">
   -
  </button>
  <button type="button">
   +
  </button>
</div>

Cool! This is gonna look terrible and make people cry. So let's write some styles.

SCSS

We will be using SCSS and BEM syntax. It will be imported into the .js file for the component. Let's boogie:

.Counter{
  padding: 1rem;

  &__count{
   font-size: 2.5rem;
  }

  &__btn{
   padding:.5rem;
   margin: .5rem;

   &--increment{
     background: lightgreen;
   }

   &--decrement{
     background: lightblue;
   }

  }
}

And let's update our HTML

<div class="Counter">
  <p>Your Count: 
   <span class="Counter__count">0</span>
  </p>
  <button type="button" class="Counter__btn Counter__btn--decrement">
   -
  </button>
  <button type="button" class="Counter__btn Counter__btn--increment">
   +
  </button>
</div>

Hold up! What's with the capitalized class name?
This is simply a preference of mine since it's standard practice in React apps to name your components Capitalized. But you can do whatever you want.

JS

Ok, let's make this reusable JS with a default count of 0. We're going to do this poorly at first and then fix it up slowly. So stay with me here :)

import './Counter.scss'

class Counter {
  constructor() {
    this.count = 0;
    this.countEl = document.querySelector(".Counter__count");
    this.incBtn = document.querySelector(".Counter__btn--increment");
    this.decBtn = document.querySelector(".Counter__btn--decrement");

    this.incBtn.addEventListener("click", this.increment.bind(this));
    this.decBtn.addEventListener("click", this.decrement.bind(this));
  }

  increment() {
    ++this.count;
    this.updateDOM();
  }

  decrement() {
    --this.count;
    this.updateDOM();
  }

  updateDOM() {
    this.countEl.textContent = this.count;
  }
}

new Counter();

NOTE: I'm using bind under the assumption you are not using Babel... yet
Read this:
https://www.freecodecamp.org/news/react-binding-patterns-5-approaches-for-handling-this-92c651b5af56/

Ok there are more than a few issues with this approach. Let's focus on one:

Using CSS classes (meant for styling only) to handle UI

This is a big one. Relying on CSS classes or even HTML element types to access DOM is a big boo boo. If you change your class name or the element type you could be breaking functionality of your app!

So how do we address this? There are a couple approaches:

JS-specific classes in your HTML
Using special data- attributes

We're going to use method #2:

<div class="Counter">
  <p>Your Count: 
   <span class="Counter__count" data-count="true">0</span>
  </p>
  <button type="button" data-dec-btn="true" class="Counter__btn Counter__btn--decrement">
   -
  </button>
  <button type="button" data-inc-btn="true" class="Counter__btn Counter__btn--increment">
   +
  </button>
</div>

import './Counter.scss'

class Counter {
  constructor() {
    this.count = 0;
    this.countEl = document.querySelector("[data-count]");
    this.incBtn = document.querySelector("[data-inc-btn]");
    this.decBtn = document.querySelector("[data-dec-btn]");

    this.incBtn.addEventListener("click", this.increment.bind(this));
    this.decBtn.addEventListener("click", this.decrement.bind(this));
  }

  increment() {
    ++this.count;
    this.updateDOM();
  }

  decrement() {
    --this.count;
    this.updateDOM();
  }

  updateDOM() {
    this.countEl.textContent = this.count;
  }
}

new Counter();

Ok a little better. The DOM is looking slightly more declarative and we can mess with our CSS all we want now. We just added super blunt and really poorly thought-out attributes.

We can make this even better. What if we set our own standard for DOM querying attributes? Moreover, what if the values of those attributes meant something too?

Let's enhance our HTML.

We're going to draw from React and Vue by using something called refs. refs are short for "reference" as in DOM reference. It's simply caching a DOM element in JS. So let's use a standard data-ref attribute:

<div class="Counter">
  <p>Your Count: 
   <span class="Counter__count" data-ref="count">0</span>
  </p>
  <button type="button" data-ref="decrement" class="Counter__btn Counter__btn--decrement">
   -
  </button>
  <button type="button" data-ref="increment" class="Counter__btn Counter__btn--increment">
   +
  </button>
</div>

import './Counter.scss'

class Counter {
  constructor() {
    this.count = 0;
    this.countEl = document.querySelector('[data-ref="count"]');
    this.incBtn = document.querySelector('[data-ref="increment"]');
    this.decBtn = document.querySelector('[data-ref="decrement"]');

    this.incBtn.addEventListener("click", this.increment.bind(this));
    this.decBtn.addEventListener("click", this.decrement.bind(this));
  }

  increment(){
    ++this.count;
    this.updateDOM();
  }

  decrement(){
    --this.count;
    this.updateDOM();
  }

  updateDOM(){
    this.countEl.textContent = this.count;
  }
}

new Counter();

Ok this isn't the worst thing in the world. The DOM is slightly more declarative.

Let's address one minor issue:

How do we differentiate state fields from DOM fields?

Let's wrap state fields in a state object and refs in a $refs object ( a la Vue):

import './Counter.scss'

class Counter {
  constructor() {
    this.state = {
      count: 0
    };

    this.$refs = {
      countEl: document.querySelector('[data-ref="count"]'),
      incBtn: document.querySelector('[data-ref="increment"]'),
      decBtn: document.querySelector('[data-ref="decrement"]')

    };

    this.$refs.incBtn.addEventListener("click", this.increment.bind(this));
    this.$refs.decBtn.addEventListener("click", this.decrement.bind(this));
  }

  increment(){
    ++this.state.count;
    this.updateDOM();
  }

  decrement(){
    --this.state.count;
    this.updateDOM();
  }

  updateDOM(){
    this.$refs.countEl.textContent = this.count;
  }
}

new Counter();

But we have at least two major issues:

How do we know what object data-ref belongs to?
How can we get rid of these .bind calls?

Enter Babel!

Babel can take modern and proposed syntax and make is ES5 readable.
We're going to rely on two things:

class-public-fields https://github.com/tc39/proposal-class-public-fields
template literals https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals

Let's tackle #1:

import './Counter.scss'

class Counter {
  constructor() {
    this.state = {
      count: 0
    };

    this.$refs = {
      countEl: document.querySelector('[data-ref="count"]'),
      incBtn: document.querySelector('[data-ref="increment"]'),
      decBtn: document.querySelector('[data-ref="decrement"]'),

    };

    this.$refs.incBtn.addEventListener("click", this.increment);
    this.$refs.decBtn.addEventListener("click", this.decrement);
  }

  increment = () => {
    ++this.state.count;
    this.updateDOM();
  }

  decrement = () =>{
    --this.state.count;
    this.updateDOM();
  }

  updateDOM = () => {
    this.$refs.countEl.textContent = this.count;
  }
}

new Counter();

bingo bongo! No more bind!

Now let's tackle #2.
For this we are going to assume we may want to update the attribute name data-ref in the future (it's far-fetched, but trust me these refactors happen!)

Let's preface our HTML attribute values with our component name

<div class="Counter">
  <p>Your Count: 
   <span class="Counter__count" data-ref="Counter.count">0</span>
  </p>
  <button type="button" data-ref="Counter.decrement" class="Counter__btn Counter__btn--decrement">
   -
  </button>
  <button type="button" data-ref="Counter.increment" class="Counter__btn Counter__btn--increment">
   +
  </button>
</div>

Let's update the JS

import './Counter.scss'

const ref = 'data-ref'

class Counter {
  constructor() {
    this.state = {
      count: 0
    };

    this.$refs = {
      countEl: document.querySelector(`[${ref}="Counter.count"]`),
      incBtn: document.querySelector(`[${ref}="Counter.increment"]`),
      decBtn: document.querySelector(`[${ref}="Counter.decrement"]`)

    };


    this.$refs.incBtn.addEventListener("click", this.increment);
    this.$refs.decBtn.addEventListener("click", this.decrement);
  }

  increment = () => {
    ++this.state.count;
    this.updateDOM();
  }

  decrement = () =>{
    --this.state.count;
    this.updateDOM();
  }

  updateDOM = () => {
    this.$refs.countEl.textContent = this.count;
  }
}

new Counter();

This is pretty darn good so far. But it's not reusable. What if we have multiple Counters? The fix is pretty simple. We're going to create a $root DOM reference.

<div class="Counter" data-component="Counter">
  <p>Your Count: 
   <span class="Counter__count" data-ref="Counter.count">0</span>
  </p>
  <button type="button" data-ref="Counter.decrement" class="Counter__btn Counter__btn--decrement">
   -
  </button>
  <button type="button" data-ref="Counter.increment" class="Counter__btn Counter__btn--increment">
   +
  </button>
</div>

Let's update the JS

import './Counter.scss'

const ref = 'data-ref'

class Counter {
  constructor(root) {
    this.$root = root;
    this.state = {
      count: 0
    };

    this.$refs = {
      countEl: this.$root.querySelector(`[${ref}="Counter.count"]`),
      incBtn: this.$root.querySelector(`[${ref}="Counter.increment"]`),
      decBtn: this.$root.querySelector(`[${ref}="Counter.decrement"]`)

    };


    this.$refs.incBtn.addEventListener("click", this.increment);
    this.$refs.decBtn.addEventListener("click", this.decrement);
  }

  increment = () => {
    ++this.state.count;
    this.updateDOM();
  }

  decrement = () =>{
    --this.state.count;
    this.updateDOM();
  }

  updateDOM = () => {
    this.$refs.countEl.textContent = this.state.count;
  }
}

Now we can instantiate multiple Counters like so:


const counters = Array.from(document
.querySelectorAll('[data-component="Counter"]'))
.map(element => new Counter(element));

So there is a framework-less way to make components. You can prepopulate your DOM using HTML fragments/mixins/partials (whatever your template language refers to as "chunks reusable of HTML".

There are obviously some bigger things to deal with here:
Passing state in, scoping components, etc. And that's where I've made a small 2kb library for handling all those things and more without you having to manually scrape any DOM and bind any events. You can declare it all in your HTML and let the library take over.

Check it out. Let me know your thoughts! I find this is a pretty decent solution for enterprise applications:

My Library for Handling Above Code and MORE!
https://github.com/tamb/domponent

And here is the end result of what we just made:

https://codesandbox.io/s/component-example-ij1zs

Making Components with Template Engines

Tamb — Mon, 14 Oct 2019 02:13:17 +0000

There's no doubt that components are here to stay. Templating, in the traditional sense, is kind of fading. At best you wrap all your React components in a layout partial and call it a day. Every chunk of reusable UI is becoming Virtual DOM or is at least migrating that way.

But what if you're stuck with using tried and true template engines like JSP, Thyemleaf, Pug, or Razor? Are you doomed to Partial-Hell forever?

Not really. You can still build React-like components with Vanilla JS and HTML includes with the ultralight framework Domponent.

For the sake of brevity, let's define a component as having the following and let's base our Vanilla JS on React:

Declarative Markup
Event Handling
Cached DOM references
Internal State

Just for good measure here are the component structures:
And here's our directory structure:

React

components/
  |
   Counter/
      |
      |Counter.js
      |Counter.scss

Domponent

components/
  |
    Counter/
      |
      |Counter.html
      |Counter.js
      |Counter.scss

Declarative Markup

Let's make a counter in React. Here's our JSX.

<div>
  <div>{this.state.count}</div>
  <button type="button" onClick={this.decrement}>
   -1
  </button>
  <button type="button" onClick={this.increment}>
   +1
  </button>
</div>

Super simple. Super easy to understand. One button increments, one decrements, and a div shows the count.

How might our HTML look:

<div data-component="Counter">
  <p data-bind="state:Counter.count">0</p>
  <button data-action="click->Counter.decrement">
    -1
  </button>
  <button data-action="click->Counter.increment">
    +1
  </button>
</div>

Let's pick this apart by the data- attributes:

data-component defines which Component your Markup is tied to. It acts as a root element for your component.

data-bind is a bit more complex. The left side of the colon : dictates that we are binding state. Much like this.state.count in React. The right side of the colon represents the Component we are retrieving state from. Then you break down the right side by its period . The left side is still the Component, while the right side is the key inside of the component state we are displaying. So here's a quick overview:

state:Component.stateKey

Event Handling

data-action is an attribute that accepts any Event type addEventListener accepts and can event accept options.

The basic html you need is

data-action="eventtype->component.method"

Now you can tie your button in your javascript like so:

import { Component } from "domponent";

export default class Counter extends Component {
  constructor(el) {
    super(el);
  }

  increment() {
    this.setState({ count: this.state.count + 1 });
  }

  decrement() {
    this.setState({ count: this.state.count - 1 });
  }
}

Cached DOM references

Each class in domponent has a $root which is the DOM node that contains data-component. You can reference it inside your component class with this.$root

data-ref works as a simple tag to tell Domponent to cache this node in memory.

data-ref="component.refName"

You can then access the element with this.refName where this is the component instance and `refName is the field name you give the cached element.

data-ref-array works similarly but it assigns the value as an array in your component and can hold multiple elements.

Internal State

Each Component has the following lifecycle methods:

stateWillUpdate
propsWillUpdate
propsDidUpdate
stateDidUpdate

These are exposed and will be called in order every time you fire this.setState. setState updates the internal state of the component and updates any relevant data-bindelements and any child components that rely on its state.

So that's it. You can check out some examples of the markup using some popular template engines here

Let's Make Components with HTML!

Tamb — Wed, 02 Oct 2019 20:34:38 +0000

Sometimes you work on front-end teams that use bleeding edge tech... Sometimes you inline all your CSS...
Most of the time, you're somewhere in between. And that's a reasonable place to be.

A lot of people are using Virtual DOM implementation for everything. And I've been seeing fewer people using Bootstrap or native DOM Manipulation. In fact, there are articles out there thate say to NEVER manipulate the DOM directly. That really doesn't make sense. The DOM exposes an API and APIs are meant to be used.

So the question is, how the H do you create standards for making Component-driven (ie: reusable) Markup without a thick abstraction layer?

I've been working in teams that use template engines like JSP, Thymeleaf, Pug, for years now. At first, the Revealing Module pattern was a life saver. This was how I wrote all my features (it also used to include jQuery). All of my DOM queries were based on HTML classes like class="js-button" or class="js-counter". And if I had nested classes I had to start getting more and more specific with my names.

So a counter might look like this:

<div class="counter">
  <p class="js-count">
   12
  </p>
  <button class="js-minus">
   -
  </button>
  <button class="js-plus">
   +
  </button>
</div>

I then had to use addEventListener and cache DOM in variables and throw it all inside a module.

This did NOT scale well. Not only did my js-dependent classes get mixed up with my styling classes, but I had to read through my entire component javascript just to see what HTML was necessary. It became a nightmare when it started growing.

So I started messing around and chatting with other devs, and I began compiling a bunch of standards. I packaged these all into a very small < 2kb framework for creating vanilla components with declarative HTML.

It's called Domponent

And it made my guesswork above into something declarative and lightweight"


<div data-component="Counter">
  <p data-bind="state:Counter.count">0</p>
  <button data-action="click->Counter.decrement">
    -1
  </button>
  <button data-action="click->Counter.increment">
    +1
  </button>
</div>

And when using it you don't need to add additional eventListeners or cache DOM nodes, you can declare it all in your HTML and the framework will wire things up for you. So all the JS you need to write is this:

import { Component } from "domponent";

export default class Counter extends Component {
  constructor(el) {
    super(el);
  }

  increment() {
    this.setState({ count: this.state.count + 1 });
  }

  decrement() {
    this.setState({ count: this.state.count - 1 });
  }
}

Looks kinda like a React component, feels kinda like regular ol DOM. It's Domponent.

Check it out. See if the extra 2kb might make your next project easier to reason about. Even if you don't use it, check out the data-api for a good idea of some standards that may make your life a boat load simpler!

Peace and Love,

Tamb

DEV Community: Tamb

Getting Weird: "Hooks" in React Class Components

The "Hook"

Component 1

What have you Lost and Gained with Front-end Complexity?

Are React Hooks Actually Worth Using?

What JS Libraries Have You Made?

Bootstrap Native. Bootstrap WITHOUT jQuery Today

Size

Dependencies

What about Bootstrap v5? Isn't that Vanilla?

Conclusion

Dear WHATWG, fix datalist

datalist weaknesses:

React vs Preact vs Inferno

Preact

Pros:

Cons:

Inferno

Pros:

Cons:

Conclusion

Resources:

Modern Front-end with Older Tech

The directory structure

HTML

SCSS

JS

Making Components with Template Engines

Declarative Markup

Event Handling

Cached DOM references

Internal State

Let's Make Components with HTML!

`datalist` weaknesses: