DEV Community: Vanderlei Alves da Silva

AI Doesn't Write Great Software—Great Engineering Systems Do

Vanderlei Alves da Silva — Wed, 15 Jul 2026 08:07:27 +0000

I see a recurring pattern in how experienced engineers react to AI-generated code: measured skepticism about its production readiness. That skepticism is legitimate when pointed at naive, prompt-and-ship workflows — but it often misses where the real engineering challenge sits.

The quality of AI-generated code is largely a function of the environment it runs in. Projects where agentic coding works well share a common trait: significant engineering investment went into defining the harness before the model was ever invoked. The code that comes out is not impressive because the model is impressive — it is because the spec is precise, the constraints are enforced, and the feedback loop is automated. That investment is non-trivial, and it is where I believe engineering teams have the most valuable contribution to make today.

There is also a subtler point worth making explicit: in this paradigm, code should be treated as a derived state — an artifact produced from a specification, not the specification itself. If the spec changes, the code is regenerated. If the code conflicts with the spec, the code is wrong, not the spec. This inverts the traditional relationship where the codebase is the source of truth and documentation trails behind it. It also has practical implications for how we handle merge conflicts: when two agents produce conflicting implementations, the resolution happens at the spec level, not the code level. Code conflicts are a symptom of spec ambiguity.

Three interlocking concepts structure how I think about this: Spec-Driven Development, Harness Engineering, and Loop Engineering. Each addresses a different layer of the problem, and none is sufficient without the other two.

Spec-Driven Development

The first discipline shift is moving the center of gravity from the prompt to the specification. In Spec-Driven Development (SDD), the spec is not scaffolding you discard once coding begins — it is the artifact from which implementation is derived, validated, and iterated.

This matters because AI agents are extremely sensitive to the quality of their inputs. An underspecified prompt produces underspecified code. A well-structured specification — covering intent, constraints, acceptance criteria, and architecture principles — gives the agent the context it needs to make consistent, coherent decisions across a non-trivial task.

Practically, this means establishing a constitution (governing principles and standards) before you write a single line of production code: naming conventions, testing expectations, API standards, security boundaries. These constraints are not bureaucratic overhead — they are the mechanism by which you steer the model.

GitHub's Spec Kit is a practical open-source toolkit that operationalises this workflow. It provides a structured pipeline of slash commands (/speckit.constitution, /speckit.specify, /speckit.plan, /speckit.tasks, /speckit.implement) that guide both the developer and the agent through progressive refinement — from high-level intent down to executable tasks — rather than asking for everything in a single prompt.

Harness Engineering

Spec-Driven Development solves the input problem. Harness Engineering solves the environment problem.

A harness is the totality of context, constraints, and feedback signals that surround the model at runtime. It has two sides:

Guides (feedforward): structured inputs that shape what the model produces — AGENTS.md or CLAUDE.md, spec and task files, architecture documentation, coding conventions. These are the instructions the model reads before acting.
Sensors (feedback): automated signals that evaluate what the model produced — linters, type checkers, test suites (unit and E2E), and review agents. These close the loop by surfacing errors the model must correct.

The harness also includes bootstrapping and memory mechanisms — an init.sh that primes the agent's environment, a progress.md (or equivalent session memory file) that maintains continuity across sessions, and git discipline that makes agent-authored commits reviewable and reversible.

The insight is that the model itself is not the product. The harness is. A well-engineered harness makes the model's output more predictable across different agents, different sessions, and different team members.

Loop Engineering

If harnesses add structure, Loop Engineering adds motion. It is the discipline of designing agentic workflows as closed feedback loops rather than linear pipelines.

In a loop, the agent does not just execute — it generates, observes, corrects, and re-generates. The sensors in the harness (tests failing, types mismatching, a review agent raising a concern) become signals that drive the next iteration. The model is no longer a one-shot code generator; it is a participant in a continuous refinement cycle.

This is a fundamental shift in how we think about software construction with AI:

Vibe Coding	Loop Engineering
One prompt → one output	Iterative cycles with feedback
Developer reviews output manually	Automated sensors surface issues
Context is lost between sessions	Memory and init files preserve state
Quality depends on prompt luck	Quality emerges from loop convergence

The transition to Loop Engineering also changes what engineers need to be good at. The skill is no longer writing the most impressive single prompt. It is designing the harness, calibrating the sensors, and structuring the spec so the loop converges reliably.

Putting All Together

Spec-Driven Development ensures the model always has a well-structured, intentful input. Harness Engineering provides the environment that surrounds the model — guides to steer it, sensors to correct it, memory to sustain it. Loop Engineering is the operating mode that ties everything together: the model runs inside the harness, receives feedback from the sensors, and iterates until convergence.

None of the three is sufficient alone. Without a spec, the harness has nothing meaningful to validate against. Without a harness, even a perfect spec produces unreliable results. Without a loop, both the spec and the harness are one-shot artifacts rather than living parts of an engineering system.

Practical Implications

For teams moving toward agentic development, these concepts translate into concrete engineering decisions:

Treat AGENTS.md / CLAUDE.md as a first-class engineering artifact. It is the primary feedforward guide. Version it, review it, evolve it.
Adopt a spec-first workflow. Use GitHub Spec Kit or equivalent to enforce constitution → spec → plan → tasks before implementation begins.
Invest in automated sensors. The ROI of a test suite multiplies in an agentic context — tests are not just quality gates for humans, they are correction signals for the model.
Design for session continuity. An agent that loses context between sessions is inefficient. progress.md, memory files, and structured init scripts are not optional niceties — they are part of the harness.
Measure loop convergence, not prompt quality. The right metric is: how many iterations does it take for the model to produce output that passes all sensors? Optimise for that, not for the impressiveness of individual outputs.

The future of software engineering is not about having the best prompt. It is about building the best harness.

The Open Question: Token Economics

There is one dimension of this I do not have a satisfying answer to yet: cost.

Loop Engineering, by design, is token-intensive. Every feedback cycle — a failed test triggering a correction, a review agent raising a concern, a type error being resolved — consumes tokens. Multiply that by the number of sensors, the number of iterations per task, and the number of tasks in a non-trivial project, and the expenditure grows fast. Add the risk of a loop that never converges — a genuinely hard engineering problem the model cannot solve within its constraints — and you have a potential runaway cost with no deterministic ceiling.

How should businesses reason about this? Right now, I think the honest answer is: we are still figuring it out. The economics today look like: token cost is a proxy for engineering time saved, but the exchange rate is opaque and volatile. Some loops are efficient. Others — particularly those dealing with ambiguous specs or poorly calibrated sensors — are not. The harness quality directly determines how expensive the loop gets, which is another argument for investing in it upfront.

There is also a model trajectory argument. The reasonable expectation is that future models — whether transformer-based or built on architectures we have not standardised on yet — will require fewer tokens to achieve the same outcome. Inference efficiency is an active research and engineering frontier. The same task that takes 50k tokens today may take 5k in two years. That would fundamentally change the economics and make loops that are currently prohibitive much more viable.

But I would not bet an engineering strategy on that timeline — and the external signals are not encouraging. On July 14, 2026, New York became the first US state to impose a one-year moratorium on new hyperscale datacenters, citing rising utility bills, water usage, and grid risk. [^1] Seattle had already enacted a similar ban in June. More than a dozen other states are considering the same. Token spend is not an abstraction: it maps directly to power draw, cooling, and water consumption in physical infrastructure that communities are now actively pushing back on. The efficiency trajectory I described assumes that capacity continues to grow. That assumption is no longer guaranteed.

For now, the practical posture is: design loops that terminate, build harnesses that reduce iteration count, and treat token spend as a signal about spec and harness quality — not just a cost to absorb.

[^1]: "New York becomes first state to impose one-year pause on new AI datacenters", The Guardian, July 14 2026. https://www.theguardian.com/us-news/2026/jul/14/new-york-moratorium-ai-datacenters

Bringing Web3 Principles to Enterprise Systems

Vanderlei Alves da Silva — Mon, 27 Oct 2025 07:26:02 +0000

While getting back to the basics of the blockchain architecture some rather philosophical thoughts just popped up into my mind, the enterprise software landscape is build around centralized platforms, potentially build in a distributed manner but vendor locked-in, and opaque systems that businesses have accepted as "just how things work." But ...

What if these systems were built on fundamentally different way? On Web3 principles? How would they look like??

This article series explores this question through a proof-of-concept: a blockchain-based booking system that aims to validate whether Web3 principles can address real enterprise challenges while meeting strict regulatory requirements like GDPR.

Web3.0: Is that still a thing?

Though the cryptocurrencies continue steady striving the term Web3.0 doesn't feel to follow the same path. Looking by the main articles on the topic most of them used to date back 2 to 3 years, we could naturally argue that the boom of AI and the shallow specialists writing about it everywhere, have left the internet a bit more "poor" in terms of variety of content, still the way I see it, the web3.0 term sounded more as a philosophical aspirational goal, which is likely not to achieve its full idealized potential.

Letting the philosophical discussion aside and going into the interesting engineering part, at its essence, Web3.0 proposes five architectural principles: decentralization (distributed control instead of central authority), user ownership (individuals own their data and digital assets), transparency (verifiable systems and open rules), trustless architecture (smart contracts execute automatically without intermediaries), and composability (interoperable systems that work together through open standards).

These aren't just blockchain buzzwords. They represent a fundamentally different way to architect systems—one that addresses real enterprise pain points like vendor lock-in, opaque pricing, high intermediary costs, and data privacy concerns.

With that in mind I want to propose the following exercise:

Can we extract its valuable principles and apply them pragmatically to solve real business problems?

The Booking Platform POC: Validating Web3 Principles

To explore whether these principles work in practice, we need a concrete example. I will call it: blockchain-based booking system.

Why a Booking Platform?

Booking systems are ideal for this exploration because they:

Have clear business logic - Rules for availability, pricing, and reservations are well-defined
Involve multiple parties - Customers, resource owners, and potentially intermediaries
Require trust - Bookings must be honored; payments must be released
Handle sensitive data - Personal information, payment details, booking history
Face real regulations - GDPR compliance is mandatory in many markets

If we can build a booking system that embraces Web3 principles while meeting regulatory requirements, we can much more confidently assert that the concept works for enterprise applications.

The Specific Web3 Principles We're Testing

This POC validates five key principles:

1. Decentralization

No central platform controls bookings
Smart contracts manage state, not a company
Anyone can verify the system's integrity

2. User Ownership

Customers control their booking data
Data can be deleted on demand (GDPR "right to be forgotten")
Booking records are portable across platforms

3. Transparency

Booking logic visible in open-source smart contracts
All transactions auditable on the blockchain
Pricing rules are transparent and verifiable

4. Trustless Execution

Smart contracts automatically enforce booking rules
Payments released when conditions are met
No intermediary needed to arbitrate

5. Privacy-Preserving Design

Personal data never touches the blockchain
Cryptographic hashing enables verification without exposure
GDPR compliance through architectural design

What Are We Building?

Below is the system architecture diagram showing how we're implementing these Web3 principles in practice:

The User Interface Layer serves as the entry point to the system, providing a command-line interface (CLI) built with Node.js and TypeScript. This layer represents the client, it could be any other kind of client, web page in the browser, mobile application, internet of things (IoT), you name it. But for this use-case to make things simpler, we go with a simple CLI application.

The Application Layer acts as the intelligent middleware that orchestrates all system operations. Let's think of it as a backend services which houses five critical services: the Blockchain Service interfaces with Ethereum using Ethers.js to handle all blockchain transactions; the Encryption Service to generate unique key pairs for each booking and performs AES-256-GCM encryption on personal data; the Storage Service which manages the lifecycle of encrypted data stored off-chain; the Wallet Manager securely handles user cryptographic identities and signing operations; and the Config Manager maintains network settings and system configuration. This layer is responsible for the critical separation between what goes on-chain (only hashes) and what stays off-chain (encrypted personal data). More on that later :)

The Blockchain Layer represents the immutable, transparent core of the system running on Ethereum. At its heart are smart contracts written in Solidity that contain all booking business logic—resource management, availability checking, and booking state transitions. These contracts interact with the broader Ethereum network through a JSON-RPC Provider that connects to Ethereum nodes. Crucially, this layer stores only cryptographic hashes and public booking metadata (dates, prices, status) while keeping zero personal information. The blockchain serves as the source of truth for booking existence and availability, providing transparency and preventing double-booking through distributed consensus.

The Off-Chain Storage Layer is the privacy-preserving counterpart to the blockchain, designed specifically to handle sensitive personal data in a GDPR-compliant manner. It consists of an Encrypted Data Store (PostgreSQL, MongoDB, or any other storing mechanism) that holds encrypted personal information, a separate Key Vault that stores encryption keys in isolation from the data they protect, and a Privacy API that manages GDPR operations like data export and the "right to be forgotten." The architectural decision to separate encrypted data from encryption keys is critical—when a user requests deletion, removing the keys makes the encrypted data mathematically irretrievable, achieving GDPR compliance while leaving blockchain hashes untouched.

The Storage component represents two distinct persistence mechanisms: Local Storage for user-side data like wallet keystores and configuration files, and On-Chain Storage within the blockchain itself that holds only hashes and non-sensitive booking metadata. This dual storage approach reinforces the system's privacy-first design—sensitive data never crosses into blockchain storage, while blockchain benefits (immutability, transparency, auditability) are preserved through cryptographic hashes that prove data existence without revealing its contents. The integration between these storage types is mediated entirely through the Application Layer, which ensures proper encryption, hashing, and separation of concerns throughout the data lifecycle.

Ethereum as the Blockchain Platform

Ethereum for those who still may be in doubt of what exactly it is, is a decentralized computing platform that runs on a global network of computers instead of a central server. This means that no single company controls the system, a capability we are really looking for this exercise, and applications built on Ethereum — called decentralized apps (dApps) — continue to run as long as the network exists.

For a booking platform, Ethereum and dApps bring interesting possibilities. Instead of depending on one central business to record reservations, availability and payments, the blockchain can ensure the records are shared, trusted, and consistent across all participants — hotels, partners, and users. Smart contracts could automatically handle payments, deposits, cancellations, loyalty points, insurance, or secondary resale of bookings without intermediaries. And since the system is open and auditable, fraud and double-booking become much harder.

Coming Up Next

This article aimed to establish the why Web3 principles matter and what we're building. The next articles will dive into how, exploring the implementation in details, having a bit of fun in the way while playing with: Ethereum blockchain platform, Solidity code, business logic on-chain, and how to build contracts that enforce rules transparently while respecting privacy.

View the Architecture

If you got interested and want to dive into all details just goal ahead in the following link to the public repo, which though still a WIP, already have an extensive system architecture in place:

Or view the complete codebase on GitHub

A piece o merchandising

Lastly a small pause for sharing you some very exciting new, at least for myself :), recently I've just released my first book:

Micro Frontends Architecture for Scalable Applications

Which bring lots of architectural insights about the frontend development, and more specifically about the micro-frontends, go a head have a look and let me know your thoughts.

Did you find not connected to web3.0, blockchains and this article at all? Yeah, indeed is not, but why would we put boxes around what we can work/learn if we can explore them all ...

Thanks for reading and let me know your thoughts/feedbacks/comments and or any other thing you may find relevant to share!

NextJS Progressive Web App

Vanderlei Alves da Silva — Tue, 17 Mar 2020 07:36:54 +0000

What if we could quickly setup a progressive web app, with server side rendering and routing mechanism out of the box? Would that sound interesting? That’s why you here, stick with me and enjoy the road.

It all starts with NextJS, we install it and run it as the following code:

"scripts": {
    "dev": "next",
    "build": "next build",
    "start": "next start"
},

The first question that come up is why would we go to a different approach to start a react project other then create-react-app? The question is pretty straightforward, if you wanna have server side rendering and a better and easy way to work offline. You not sure? Here it goes …

create-react-app comes out of the box with an offline support, however it’s restricted in how stores locally its assets. It restricts us to the generated assets (js, css, images, fonts ...), however what if you also wanna store CDN files, backend apis, system specific routing? How would go there, probably ejecting your project and(or) using other libraries, such as react-app-rewired, but at the end these approaches soon or late end up adding more complexity to your code and more code to maintain .. Anyway why would you enjoy maintaining custom script building systems?

Now take a look at this code:

const isProd = process.env.NODE_ENV === "production";

const withPWA = require("next-pwa")

module.exports = withPWA({
 pwa: {
   disable: !isProd,
   dest: "public"
 }
})

With a simple higher order function we add the desired functionality! Too fast? Let’s digest this properly.

First thing first, have a look on this dummy example (if you wanna fully experience all features, use chrome, nothing against the others, but while I’m writing this article, progressive web app functionalities are still a work in progress and the installable option of our app will not work on them)

Once you there, open the developer tools and check while you navigate and/or refresh the pages, the resource (js, css, fonts, api calls ..) are being locally saved:

Check also on the plus icon right after the website url bar:

And if you inspect the network tab, you’ll see that the initial load comes with all your app already rendered from your server .. :)

That’s it, these are the user functionalities of our dummy app, disable the internet connection and then you can see a friendly message saying that there is no connection and the app still working.

But then now it comes the question, how is that done? Tired of reading? Go directly to what matters: the code!

The implementation is as NextJS project, using MaterialUI for the interface elements, Typescript for type checking, next-pwa a next plugin for the progressive web app functionalities and a quick bonus, check this code. An MDX support for next provided by next-mdx.

If you look at the code you may notice the absence of a routing coding, a react-router or similar, that’s NextJS in action, it gives an automatic routing system, just put your routes under page folder and the routing is done:

Wondering how does it work and how is that done, check here: https://nextjs.org/docs/routing/introduction

Here we can clearly see how easy can be set a project with advanced feature just by choosing the right tools, because at the end, the heavy work of a developer is not developing thing and yes choosing the right tools for what we need.

There is so many nice wheels to be used, why would we create our owns? Let’s grab them and construct our beautiful cars!

Middlewares with react context and hooks

Vanderlei Alves da Silva — Mon, 07 Oct 2019 07:32:11 +0000

Continuing the idea explored in the previous article of having a global state management using pure react (with react context and hooks), we’re going to explore now how to take advantage of the middlewares concept, implementing for that a loger and localStorage middleware to our todo app, check here the live demo and here the source code

About middlewares

The term can slightly differ from each depending on the middleware type (Database Middleware, Integration Middleware, Application Middleware, Object Middleware, Remote Procedure Call (RPC) Middleware, Message Oriented Middleware ...) but essentially they have the idea of a composable peace of code running in the middle of to distincts processes improving their communication, and by process we could use more specific terms according to the scenario that we are talking about.

In the web development niche this term is spreedly used in server side technologies such as Laravel, ExpressJS, nestJS among others as:

A composition of functions that are called, in a given order, before the route handler and that usually each one of them have access to the request information and a reference to the next function in this chain

This idea was taken by the front-end fellows, mainly applied by the state management libraries: redux, mobx, vuex (the last even though with a different nomenclature “plugin” the idea is the same), and what they all do is to provide a way of running some code between dispatching an action, and the moment it changes the application state.

Of course this concept can be used in other scenarios, this article explores its usage attached to the router change in angular, getting closer to the above mentioned server-side ones. But for now we’re going to explore the first one.

Show me the code

import { initial, final } from './log';
import localStorage from './localStorage';

export default ({ state, action, handler }) => {
  const chain = [initial, handler, localStorage, final];

  return chain.reduce((st, fn) => fn(st, action), state);
};

That’s all what matters, we need a function to create a middleware chain and execute all them in a given order and of course call our handler (the reducer function called by a given action in our application).

const chain = [initial, handler, localStorage, final]

Here we define the middlewares that will be called and in which order they will, the ones that comes before handler are the pre-middlewares (you put here all middlewares that you want to run something before the state have changed) and the others the post-middlewares (the ones that execute something with the new state).

The middleware function signature follows the same pattern of the reducers:

(state, action) => newState

As an example here is the initial log middlewares:

const initial = (state, action) => {
  console.log(action);
  console.log(state);
  return state;
};

The middleware just log the initial state (before the state have being change by the reducer) on the console.

Here we have a more interesting one:

import store from 'store2';

export default state => {
  store.set(state.storeId, state);
  return state;
};

This middleware saves the current state on the local storage, I’m using for this a small library store2 just to make sure retrocompatibility with old browsers and also avoiding working with try catch statements.

I have on the app state an storeId property with the name of the key that will be saved on the local storage, so basically in this call:

store.set(state.storeId, state);

I store in the given key the given state. If you check the app again, play around and refresh the page, the information will still be there.

And lastly we have:

return chain.reduce((st, fn) => fn(st, action), state);

We use the reduce array method to iterate over each item of the chain getting the result of the previous and passing to the next item.

There it is

We have now returned to the basics and explored how the main state management libraries conceptually work with middlewares, giving us the same results with less dependencies and less complexity. We now understand what happens, instead of just blindly using them.

What do we got from it!? A better reasoning of when to use these state libraries.

What do we go from now!? More hooks on the way, check here the new custom hooks from react-router-v5.1 and see you soon. ;)

References

https://dev.to/vanderleisilva/global-state-management-with-react-hooks-and-context-5f6h
https://vanderleisilva.github.io/react-context/
https://laravel.com/docs/6.x/middleware
http://expressjs.com/en/guide/using-middleware.html
https://docs.nestjs.com/middleware
https://redux.js.org/advanced/middleware
https://github.com/mobxjs/mobx-state-tree/blob/master/docs/middleware.md
https://vuex.vuejs.org/guide/plugins.html
https://www.w3schools.com/jsref/jsref_reduce.asp
https://reacttraining.com/blog/react-router-v5-1/

Global state management with react hooks and context

Vanderlei Alves da Silva — Tue, 24 Sep 2019 07:33:09 +0000

From prop drilling to centralized global state management with react

It all started with amazing frameworks like react, vue, angular and some others that have had the brilliant idea of abstracting the application data from the document object model (DOM). React specifically, with your reconciliation algorithm and soon with the fiber architecture, rocks on how fast these layers (abstraction and DOM) are updated. With that we can focus on our components instead of the “real” HTML implementations, however from that also come some other new challenges, let’s put it in images:

That’s the classical prop drilling react anti-pattern, the process of going through the react component tree in order to pass properties between them. Higher order components or Decorators, if you are in a more object oriented style, give us more flexibility and some others architectural possibilities. We can now extract away that functionality which we want to share and decorate the components that need use it.

It’s all fine while dealing with small apps with few components interacting with each other, however when we have complex communication between a vast component ecosystem than this approach starts getting complicated and bug prone. From that reality our unidirectional data flow comes into stage:

Until here nothing new, but what if we take the concept and apply it using react context and hooks!? That’s why you here!

Main concept

The main highlight by now is our great and new friend react hooks, and your consequently functional approach:

Hooks are a new addition in React 16.8. They let you use state and other React features without writing a class.

Then the center idea is to use the context API together with useContext and useReducer hooks to make our store available to our components.

import React, { createContext, useContext, useReducer } from 'react';

export const StateContext = createContext();

export const StoreProvider = ({ reducer, initialState, children }) => (
  <StateContext.Provider
    value={useReducer(reducer, initialState)}
    children={children}
  />
);

export const useStore = () => useContext(StateContext);

We export from this file source code here a StoreProvider (responsible for making the context/store available in the application), that receives:

the reducer function with the signature (state, action) => newState;
application initialState;
and the application content (children);

And the useStore hook that is responsible for getting the data from the store/context.

Even though the nomenclatures are different from now on I’ll reference our context as store, because the concept is the same and we can easily associate to our well known redux architecture standard.

The beauty relies on this simplicity:

StateContext.Provider receives a value object (your current state);
useReducer receives a function: (state, action) => newState and an initialState then any dispatch made from our app will pass here and update our application current state;
useContext get our store and make it available in our application!

All the rest is just code organization and minor changes, nothing to worry about :)

Going into details

As a proof of concept, I’ve done this basic todo list application, check here the source code and here the live implementation, it’s a basic interface that contains a couple of component and the current state tree so then we can see the state modifications over the time.

The project structure looks like this:

The structure is pretty straightforward (action as we’d normally do in a redux application), I’ve moved the initialState from the reducers, because reducer is about state modification and not definition, besides that the store folder contains the already discussed react context / hooks implementation.

The reducer file has a quite different design:

import * as todo from './todo';
import * as types from 'actions/types';

const createReducer = handlers => (state, action) => {
  if (!handlers.hasOwnProperty(action.type)) {
    return state;
  }

  return handlers[action.type](state, action);
};

export default createReducer({
  [types.ADD_TODO]: todo.add,
  [types.REMOVE_TODO]: todo.remove,
  [types.UPDATE_TODO]: todo.update,
  [types.FILTER_TODO]: todo.filter,
  [types.SHOW_STATE]: todo.showState,
});

The point here is just to avoid those huge switch statements usually seen in reducer functions with a mapping object, so basically for every new reducer we just add a new entrance in the mapping object.

But again, it’s all a matter of implementation the requirement here is that the function needs to have the (state, action) => newState interface as we’re already used to with Redux.

And finally but not least our component subscribing to the store:

import React from 'react';

import { useStore } from 'store';
import { addTodo, filterTodo } from 'actions';

import uuid from 'uuid/v1';

import Button from '@material-ui/core/Button';

export default props => {
  const [{ filter }, dispatch] = useStore();

  const onClick = () => {
    dispatch(addTodo({ id: uuid(), name: filter, done: false }));
    dispatch(filterTodo(''));
  };

  return (
    <Button
      {...props}
      variant='contained'
      onClick={onClick}
      disabled={!filter}
      children='Add'
    />
  );
};

What comes next

The next steps will be related to middlewares and type-checking, how do we work here? Technically the middleware is a function called just before the dispatched action reaches the reducer, so the createReducer function above is a great place for that, and what about type-checking!? Typescript on it! And see you soon!

Cheers!

References:
https://github.com/acdlite/react-fiber-architecture
https://reactjs.org/docs/reconciliation.html
https://reactjs.org/docs/hooks-intro.html
https://github.com/vanderleisilva/react-context