DEV Community: Alessandro Annini

AI Writes Better Code When You Stop Thinking in Code

Alessandro Annini — Tue, 29 Jul 2025 22:40:59 +0000

From Chaos to Clarity: Building Software with AI Starts with the Right Map

From Code to Concept

Working with AI on software projects is no longer a futuristic dream, it’s already here. But if you’ve tried building something serious with tools like Cursor, Claude Code or Windsurf, you’ve likely hit a wall: when the project is complex the AI gets lost in the code. Too many files, too many side effects, too many implicit assumptions.

That’s because code is not the best way to reason about systems for humans or AIs. We need a better abstraction layer. Something precise, high-level, shorter and deterministic. That’s where LayeredDSL comes in.

Repo: https://github.com/AlessandroAnnini/layereddsl
Try yourself: copy this guide and give it to your AI assistant.

The Problem With Code-First AI

When you ask an AI to generate or modify code, it struggles with:

Ambiguity: Codebases are filled with partial implementations, hacks, and assumptions.
Scale: Large projects span hundreds of files... which ones should be changed or even read?
Alignment: AI doesn’t always understand the why behind your design so sometimes it change it slightly.
Validation: It’s hard to check if code is “correct” without rerunning full tests.

The result? Fragile interactions, unpredictable outputs, and hallucinated features. Even when it works, you can’t fully trust it. Larger, better models used in agentic fashon solve the problems, but only partially because even if they are enough to manage a large codbase, something could be overlooked and, in the end you will pay a very high price to keep playing with a lot of tokens.

The Shift: Map-First, Code-Later

Framework to work with AI like you would with a agile team are effective and all, and I really think there is a lot of potential there but something is still too clunky, there is too much struggle and it not feels right to me. I was thinking about a way to literally work-around this and I started to wonder what would happen if, instead of reasoning through the code, you described your system’s intent in a structured, formal language? A Domain-Specific Language (DSL) that acts as a single source of truth, designed for collaboration between humans and AI

That’s the idea behind LayeredDSL.

Rather than asking AI to navigate or rewrite your codebase blindly, you collaborate with it at the design layer, where the system is defined clearly and unambiguously. The DSL becomes the contract, and code is just an implementation detail.

Why This Matters

Shifting to DSL-first development brings long-term strategic advantages:

✅ Determinism: No more guessing what the AI will do: if the DSL is complete and accurate, so will the code.
🧠 Clarity: Stakeholders, devs, and AIs all work from the same shared model.
🔁 Traceability: Every logic function is mapped to a real component so nothing is implied or lost.
🛠 Maintenance: When requirements change, you change the DSL. AI updates only the affected code.
🚀 Bootstrap speed: New modules or microservices can be generated from zero with confidence.
🔍 Code validation: The AI can also act as a linter, checking if the current code matches the spec.
🔐 Safety: Less chance of hallucinations or shadow logic because the DSL is always the source of truth.
🌐 Cross-language portability: You can implement the same DSL-defined system in a completely different programming language or framework with minimal changes to the map.

And just as importantly: a small, focused DSL document outperforms a massive codebase when reasoning with AI. Instead of re-reading thousands of tokens just to understand how a system works, the AI can rely on a compact, unambiguous, layered definition. It’s faster, clearer, and more reliable for both humans and machines.

What is LayeredDSL?

LayeredDSL is a structured YAML-based metamodel. It doesn’t describe code but instead it describes projects. Any kind of software project: web apps, APIs, microservices, mobile apps, even hybrid systems with or without AI agents.

It includes layers such as:

project: name, version, authors
domain: data models and types
logic: business functions and expected behavior
components: service/module boundaries
ui: user-facing pages and controls
workflow: ordered or conditional logic sequences
security: roles and permissions
mapping: where logic is implemented
metadata: change history

Why It Works: Design Goals

LayeredDSL was designed with the following principles:

Layered by intent: business logic is separate from data and UI
Readable: every part is easy to understand for both humans and AI
Generative + Validatable: the same DSL can be used to produce or check code
Immutable source of truth: AI never freelances beyond what the DSL says
Deterministic mapping: same DSL = same code = same behavior

Summing it all up AI can work with it so confidently. It knows what to do and what not to.

The Core Structure of LayeredDSL

Here’s a compact example that defines an invoicing app:

    project:
      name: InvoiceManager
      version: 0.1.0
      description: Track invoices and notify clients

    domain:
      Invoice:
        id: UUID
        customerId: UUID
        amount: float
        status: enum[draft, sent, paid]
        createdAt: datetime

    logic:
      CreateInvoice:
        inputs: [customerId, amount]
        output: Invoice
        modifies: Invoice
        description: Creates a new invoice.

    components:
      - id: billing_service
        type: module
        language: python
        responsibilities:
          - CreateInvoice

    ui:
      pages:
        - name: Dashboard
          route: "/"
          components:
            - type: table
              source: Invoice
              columns: [customerId, amount, status]
            - type: form
              fields:
                - name: customerId
                  type: uuid
                - name: amount
                  type: float
              onSubmit: CreateInvoice

No code yet, just a clear description of what should exist. From here, the AI can:

Scaffold the backend
Generate UI pages
Validate the current implementation
Identify missing logic
Auto-create test cases

No worries about AI creating something you didn’t discuss before and even if this would be the case, you can easily tell the assistant to remove that part from the DSL in no time, using a minimal amount of tokens.

Human + AI Cycle: Define → Validate → Generate

Working with LayeredDSL involves a clear three-phase loop:

Define

The human developer discuss the idea with the AI that drafts the DSL file. AI assists by suggesting completions or pointing out gaps.

Validate

When the DSL map is complete the AI checks whether existing code satisfies the map. If everything matches nothing more is needed.

Generate

If something is missing, the AI generates only the missing code, and only according to the DSL. No freelancing. No feature creep.

Think of it like building software from a precise architectural drawing, not a fuzzy conversation.

This cycle can be repeated across sprints, services, or even different teams. The DSL becomes your living contract with the AI.

The “One Rule”

Layered DSL map and code should always be aligned, if they are not, ask your trusted assistant to align them by modifying the DSL or the code.

Examples: Real-World DSL in Action

Here’s a simplified workflow example from a CRM:

    workflow:
      - name: LeadProcessing
        steps:
          - call: ValidateLead
            condition: lead.source == "web"

          - call: NotifySalesTeam
            loop: each user in SalesUser[]
            condition: user.region == lead.region

          - branch:
              when:
                - condition: lead.score > 80
                  call: AssignPriorityRep
                - condition: lead.score <= 80
                  call: AddToNewsletter

This structure captures control flow, decisions, and team logic in a way that is trivial for AI to interpret and clear to every human on the team.

AI Prompt Engineering for DSL

Because LayeredDSL is so explicit, you can talk to your AI assistant in terms like:

“Suggest missing workflow steps based on the logic defined.”
“Create backend code for everything in this DSL file.”
“Does CreateInvoice already exist in billing_service?”
“Generate a test plan for this logic based on inputs and output.”
“Refactor this DSL to separate customer-facing and admin UI.”

You’re no longer wrangling unpredictable LLM behavior when the code is at stake you’re using AI to make development much more deterministic by planning this on paper, with a structured document.

🧠 Final Thought

AI won’t replace developers. But it will change the way we describe, evolve, and verify software.

Many frameworks are being created to fragment ai working into specialized agents and this is super effective, but they would be a lot more effective if they could plan the work ahead and know in advance the full picture and not “blinsided” by some patchwork code they find on the code when they try to complete a task.

By moving from code to concept by describing intent instead of implementation you unlock a new level of AI-assisted development power.

And LayeredDSL might just be the missing bridge.

👨🏻‍💻 About the Author

I’m Alessandro Annini, a software engineer with 15+ years of experience across sectors from aviation entertainment systems to large-scale platforms. My work is grounded in one goal: make powerful tech accessible and practical.

Follow me on GitHub or LinkedIn to keep up with the future of portable development.

Lightning-Fast Development with Zed and Dev Containers

Alessandro Annini — Sat, 26 Oct 2024 13:50:30 +0000

Ever found yourself saying “but it works on my machine” or spent hours setting up a development environment for a new team member? Dev Containers might just be the solution you’re looking for, and now you can use them with the blazingly fast Zed editor.

What’s a Dev Container?

Think of a dev container as a pre-configured development environment in a box. It’s a Docker container that comes with all the tools, libraries, and configurations your project needs. The beauty is that it’s consistent across all machines — whether you’re coding on a MacBook Pro, a Windows desktop, or a Linux laptop.

Dev Containers can include:

Programming languages and runtimes
Build tools and package managers
Environment variables and settings
Extensions and tooling
Even GUI applications!

The best part? Everything is defined in code through a “devcontainer.json*”* file, making it version-controlled and shareable with your team.

Why Should You Care?

Onboarding Made Easy: New team member? “Clone the repo and start the dev container” — that’s it. No more multi-page setup docs.
Consistency is King: Everyone on the team uses exactly the same environment. No more “works on my machine” syndrome.
Isolation is Bliss: Each project can have its own contained environment without conflicting with other projects or your system.
CI/CD Parity: Your development environment can match your CI/CD pipeline exactly, reducing deployment surprises.

Enter Zed Tasks

Zed is a high-performance code editor that’s gaining popularity for its speed and simplicity. One of its powerful features is Tasks — a way to define and run commands directly from the editor.

Zed Tasks allow you to:

Define reusable commands in JSON
Run them with keyboard shortcuts
See output in an integrated terminal
Access editor context (like current file path or selected text)

Setup Dev Containers + Zed Tasks

While VS Code has built-in support for dev containers, we can achieve similar functionality in Zed using Tasks and the Dev Container CLI. Here’s how to set it up:

1. Install the Prerequisites

First, install the Dev Container CLI:

npm install -g @devcontainers/cli

2. Set Up Your Dev Container

Create a .devcontainer/devcontainer.json\ file in your project root. Here’s a simple example for a Node.js project:

{
  "name": "Node.js Project",
  "image": "mcr.microsoft.com/devcontainers/typescript-node:1-20-bookworm",
  "forwardPorts": [
    3000
  ],
  "postCreateCommand": "npm install",
  "postStartCommand": "npm run dev"
}

3. Configure Zed Tasks

Create a .zed/tasks.json\ file in your project root with these tasks:

[
  {
    "label": "DevContainer: Up",
    "command": "devcontainer up - workspace-folder ${ZED_WORKTREE_ROOT}",
    "use_new_terminal": true,
    "allow_concurrent_runs": false,
    "reveal": "always"
  },
  {
    "label": "DevContainer: Build",
    "command": "devcontainer build - workspace-folder ${ZED_WORKTREE_ROOT}",
    "use_new_terminal": true,
    "allow_concurrent_runs": false,
    "reveal": "always"
  },
  {
    "label": "DevContainer: Exec",
    "command": "devcontainer exec - workspace-folder ${ZED_WORKTREE_ROOT} ${1}",
    "use_new_terminal": true,
    "allow_concurrent_runs": true,
    "reveal": "always"
  },
  {
    "label": "DevContainer: Run User Commands",
    "command": "devcontainer run-user-commands - workspace-folder ${ZED_WORKTREE_ROOT}",
    "use_new_terminal": true,
    "allow_concurrent_runs": false,
    "reveal": "always"
  }
]

4. Using Your Dev Container

1. Open your project in Zed\
2. Press Cmd/Ctrl + Shift + P\ to open the command palette\
3. Type task: spawn\ and select it\
4. Choose “DevContainer: Build” to build your container\
5. Use “DevContainer: Up” to start it\
6. Run commands inside your container with “DevContainer: Exec”

Understanding Container Lifecycle Commands

Your dev container can automate setup and initialization through lifecycle commands. These commands run at different stages of your container’s lifecycle:

postCreateCommand\ Runs once after the container is created. Perfect for initial setup:

{
  "postCreateCommand": "npm install && npm run db:migrate"
}

2. postStartCommand\
Runs every time the container starts. Ideal for development servers:

{
  "postStartCommand": {
    "server": "npm run dev",
    "db": "docker run postgres",
    "watch": "npm run watch"
  }
}

3. postAttachCommand\
Runs when you connect to the container. Good for session setup:

{
  "postAttachCommand": "source ~/.nvm/nvm.sh"
}

To execute these commands in Zed, use the “DevContainer: Run User Commands” task after starting your container.

Pro Tips

1. Custom Key Bindings: Add this to your keymap.json to quickly spawn your container:

{
  "context": "Workspace",
  "bindings": {
    "alt-d u": [
      "task::Spawn",
      {
        "task_name": "DevContainer: Up"
      }
    ]
  }
}

2. One-Shot Commands: Need to run a quick command? Use the task spawn modal and type:

devcontainer exec — workspace-folder ${ZED_WORKTREE_ROOT} npm test

3. Task Variables: Use Zed’s built-in variables like ${ZED\_FILE}\ to reference the absolute path of the currently opened.

4. Combined Startup: Create a single task for starting development:

{
  "label": "DevContainer: Start Development",
  "command": "devcontainer up - workspace-folder ${ZED_WORKTREE_ROOT} && devcontainer run-user-commands - workspace-folder ${ZED_WORKTREE_ROOT}",
  "use_new_terminal": true,
  "allow_concurrent_runs": false,
  "reveal": "always"
}

Conclusion

While this setup requires a bit more configuration than VS Code’s integrated solution, it brings the power of dev containers to Zed’s lightning-fast editor. You get the best of both worlds: Zed’s performance and simplicity, combined with the consistency and isolation of dev containers.

The dev container ecosystem is growing rapidly, with support from major players like GitHub, Microsoft, and others. By setting up this workflow in Zed, you’re future-proofing your development environment while keeping it blazingly fast.

Give it a try, and you might find that dev containers + Zed is the workflow you’ve been looking for all along.

Want to learn more? Check out the Dev Container Specification and Zed’s documentation.

This is me on LinkedIn, Twitter and Github.

What’s my AGI again? Implementing an Autonomous Agent in Js

Alessandro Annini — Mon, 23 Oct 2023 14:45:20 +0000

[This article was first published on Medium]

I fired it up it was a coding night,
I used the key to get the AI right,
I started sending text, And it processed my lines,
But then it called a service, see?

😄

TL;DR: This agent library can use functions and call on itself until it finds a way to answer to the user. It’s not a real, complete **artificial general intelligence*, it’s really extremely *far from it actually, but it’s a nice experiment in that direction.

**Github repo for micro-agi-js — this article is based on v1.0.2**

[Photo by Lyman Hansel Gerona on Unsplash]

Definition of AGI in 99 words:
Artificial General Intelligence (AGI) refers to machines that possess the ability to understand, learn, and apply knowledge across a wide range of tasks, akin to human intelligence. Unlike narrow AI, which excels at specific tasks, an AGI can adapt to various challenges without prior programming. It involves complex problem-solving, reasoning, and comprehension, aiming to mimic human cognitive functions. AGI’s development is a monumental task, requiring advancements in machine learning, neuroscience, and computer science. While it holds tremendous potential, including automating complex tasks and enhancing problem-solving, it also raises ethical and safety concerns that necessitate careful consideration and robust safeguards.

It is able to reason

Actually the word “reason” is (still) misleading in the field of AI but with the AGI technique the LLM can generate a chain of thought. This is important when they cannot achieve their goal in a single iteration. This gives space for the AI to understand what it needs to satisfy the request.

Every time the script calls OpenAI it uses function calling feature to get back a structured response that can be parsed from JSON to a Javascript object.

This object contains 4 standard properties:

thought: the main idea the LLM comes up with
description: an expanded version of the thought where the LLM elaborates more
criticism: something that could be improved or some information that is missing
response: (optional) the final response that will be presented to the user

The “response” property is optional because the AI could not have an answer after the iteration so the other properties (thought, description and criticism) are given to the next iteration so the AI can continue to reason from where it left.

It is able to use tools

Another extremely powerful feature is the ability to use the tools that you teach them. More specifically you could have some functions that could help the AI during the reasoning, maybe those functions are loading data from a database or maybe they hit an API to get useful data.

Tools are functions.

If you want to make those functions available to the AI you need to describe how to use them, and you can do this using OpenAI function calling feature.

The aim is to create a clear list that explains how your tools work. For each tool, mention its name and describe what it does. If the tool needs extra information (parameters) to work, list these details too, including each one’s name, what it should be like (type), a short explanation of what it does, and whether it’s essential to use the tool properly. This way, you have a straightforward guide to help use your tools correctly.

As you can see in the example above I am trying to teach the LLM how my functions work giving them the most minimal but complete information set about them so that when it needs something that it doesn’t know, it looks for function that could help and then is able to tell you what to execute and how, giving you the parameters, if any.

An important concept here is that the LLM is always the brain only, and you are in charge to build the arms and teach it how to use them.

YOU create the functions you need to get data or whatever
YOU create an object like the example above to describe your functions to the AI
YOU send the functions definitions + your prompt to the AI
AI tells you which function is needed and the parameters to use
YOU execute the corresponding function with the parameters
a result is obtained

This OpenAI feature is really powerful as it is but it looks like magic when working in a AGI workflow!

The mission is to be able to obtain from the LLM a response that always have thought, description and criticism properties to keep alive the chain of thoughts but to the 4 main AGI properties I added a new, optional, one: **“command”. **How do I define this? Using my functions definitions.

This way the LLM can return a response for the user or can return a command to execute or maybe neither of the two because it needs an iteration to think.

Introspection

This is the typical AGI function description to have some kind of introspection about the AI thinking:

This is the part that makes possible a “reasoning” for our agent, but here, for clarity, I removed the command part.

The command property will hold what makes possible for the user to nest the definitions for their tools/functions on the previous part of the structure, the one that provides for the reasoning. This new part introduces our functions and how to use them to the agent so it can reason about if, when and how to use them.

With the first image we saw how to define my functions in a way that the agent can use them passing the definitions to OpenAI API using the feature “function calling”, well, that objet is nested right here inside the command property, so OpenAI is able to decide if it needs to ask you to use a function to get some data and how you should use it in order to get the data it needs.

The Agent

The engine of the agent is fairly simple: it exposes a function able to receive a message from outside. This message is thrown into a recursive fuction with the following steps:

Uses OpenAI completion feature ALWAYS using “function calling”
Unpacks the response from OpenAI and check if a command is present
If the response contains a **command property **it tries to execute it using the services that the user passed when the agent was created. This command and the respose of the function are then appended to the context that the agent sends to OpenAI
If the response contains a response propery then the content will be appended to the context and used to respond to the user
If the response does not contain any command nor response property, then the content is appended to the context and the recursive function calls itself for a new iteration

Coding the agent

Let’s now see the code and unpack it step by step.

When I create an agent i get an object with a signle function exposed: *processMessage. *We will begin from here.

This function gets a message from the user as input, add it to the current context as a user message and call a recursive function: *recurseUntilResponse *that, when executed for first thing calls OpenAI API to understand how to procede

fetchOpenAIResponse will use OpenAI completion and function calling with the functions that we have built in the first part of the article, then after having received a response, it checks if the response contains a command to execute or a response for the user.

If a command is found it means that I now have the name of a function to call and the necessary arguments (I am talking about the nested function of the first snippet of code).

After the selected function is executed I add the result to the context and, thanks to the recursion, it will be included in the next iteration and sent to the next call to OpenAI that (hopefully) will use the result to formulate a response for the user.
If the data is still not what is needed to respond to the user, the LLM could decide to call another function during the next iteration.

If a response is found it means that the LLM found a way to answer to the user, maybe because the context was containing enough data (thanks to previous command results included in it).

The recursion stops here, the response itself is added to the context, this time with role assistant, and sent to the user.

Sometimes you will get no command or response, this happens when the data is not enough to answer to the user and maybe the LLM needs more reasoning or realize that it needs more data before it can formulate a response.

Conclusion

[Photo by Rock'n Roll Monkey on Unsplash]

This is, in brief, the anatomy of *micro-agi-js. *The library is actually a simple, experimental implementation and many improvements can be added to it. At the same time the results are quite effective and it is often capable to use many functions at the right time, the right way. This, in my opinion enables many new, useful, paradigms in a wide range of scenarios in a way that is absolutely fascinating, technically effective and still a powerful marketing weapon.

I am already working to a new implementation that includes limits to the API calling, embeddings and the ability to have a conversation between different agents.

Try the library looking at the example and let me know what do you think about it and how would you change it.

This is me on LinkedIn, Twitter and Github.

PUSHARD Progressively deploy commits between AWS Amplify environments

Alessandro Annini — Fri, 03 Dec 2021 17:07:22 +0000

My Workflow

When creating a new project with AWS Amplify life is good: you have a lot of different AWS services handy and ready to be used in a integrated way. If you ever used Amplify you know what we are talking about.
Everything is fine until you begin to use Amplify environments. This is because Amplify creates a copy of every service you are using for every environment you are creating. When it comes to Appsync there is no exception.

If you need different environment like development, test and production (maybe you even have demo!) you will find yourself with three times your cognito pools (if you have authentication), three times your lambdas and three times your graphql tables. Often times when you are developing, you will have to make changes to your schema.graphql but you don't want to reflect those changes in other environments right away because maybe the UI is still not updated or simply because your work isn't completly done yet and you don't want to deploy a broken version.
The problem you can incur into is a known Amplify problem, in fact AWS even has a section on their docs about it: Deploying multiple secondary indices (GSI), and their github repository has a lot of issues about this.

Attempting to mutate more than 1 global secondary index at the same time on the <table_name> table in the stack.
An error occurred during the push operation: Attempting to mutate more than 1 global secondary index at the same time on the <table_name> table in the  stack.

If you try to modify 2 or more connections on the same table, when you try to push your changes to Cloud Formation with the command amplify push, you will get this error. When you're working on the development branch is not a big deal because you only have to make multiple "amplify push" in order to gradually change the connections state.

The REAL problem comes after you have made a number of amplify push on your development environment and you want to replicate the final schema.graphql to the test or production environment. Suppose you made 10 amplify push on your development environment but your production environment has never been updated after push number 3: now if you try to move your current schema.graphql (let's call it version 10) over your schema.graphql version 3 on production, you will have a big problem. Amplify won't be able to make multiple updates on the secondary indexes of your production tables just like it wasn't before, when you was trying to make only two updates together on the same table.

You would have to replicate the exact sequence of successful updates you made on you development environment to you production one.

Here comes into play PUSHARD!

First of all you have to make a commit on git after every amplify push on your environment.
This Git Action will then take care to grab your commit hisory from development branch, detect the exact slice of commits you need to fully replicate the development verison of schema.graphql to your target environment. In order to deploy every update it will try to merge the current development commit into target branch, launch amplify push command and finally git commit the result after every successful operation on the target branch.
If something shoud go south during the process, it will push to git everything is committed at the time, the next time it will try to pick up the process where it left off.

Now, this flow is correct from a AWS standpoint because DynamoDB will be able to update step by step its tables. But at the same time, when asking many consecutive Cloud Formation updates, especially if you created or updated a lambda in your stack too, will take longer than the time of the simple amplify push command, so, at the next iteragion of updates loop, you could have another error:

Resource is not in the state stackUpdateComplete

This means that Cloud Formation has not yet completely update your lambda resources and, because of this, it won't be able to make further updates.
Because of this you have to make a commit after every time you create or modify a lambda function. This way our Git Action will be able to successfully push the change to amplify and during the next loop iteration it will wait for Cloud Formation to be in the UPDATE_COMPLETE state before trying to update the stack again.

When the git action is starting it can send you a Telegram message writing how many commits it will take from development to the target branch; it will message you after every successful amplify push operation and if something goes wrong.

LICENSE
README

nautes-tech / pushard

Progressively deploy commits between AWS Amplify environments

PUSHARD Progressively deploy commits between AWS Amplify environments

Description

When creating a new project with AWS Amplify life is good: you have a lot of different AWS services handy and ready to be used in a integrated way. If you ever used Amplify you know what we are talking about Everything is fine until you begin to use Amplify environments. This is because Amplify creates a copy of every service you are using for every environment you are creating. When it comes to Appsync there is no exception.

View on GitHub

Submission Category:

DIY Deployments, Maintainer Must-Haves.

Yaml File or Link to Code

name: pushard

on:
  workflow_dispatch:
    inputs:
      deployHash:
        description: 'Target deploy hash'
        required: true
      skipHashes:
        description: 'Deploys to skip'
        required: false
      dstBranch:
        description: 'Destination branch'
        required: true

jobs:
  run_pushard:
    name: Run PUSHARD
    runs-on: ubuntu-18.04
    steps:
      - name: Checkout
        uses: actions/checkout@v2

      - name: Setup Node.js environment
        uses: actions/setup-node@v2.1.5
        with:
          node-version: '14'

      - name: Create working dir
        shell: bash
        run: mkdir tempdir

      - name: Install AWS CLI version 2
        run: |
          curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
          sudo unzip awscliv2.zip
          sudo ./aws/install
          sudo rm -rf awscliv2.zip
          sudo rm -rf aws
          aws --version

      - name: Install @aws-amplify/cli node package
        run: npm install -g @aws-amplify/cli@7.3.2

      - name: PUSHARD
        run: |
          echo "Target deploy hash: ${{ github.event.inputs.deployHash }}"
          echo "Deploys to skip: ${{ github.event.inputs.skipHashes }}"
          echo "Destination branch: ${{ github.event.inputs.dstBranch }}"
          cd builder
          npm install
          npm start
        env:
          DEPLOY_HASH: ${{ github.event.inputs.deployHash }}
          SKIP_HASHES: ${{ github.event.inputs.skipHashes }}
          DST_BRANCH: ${{ github.event.inputs.dstBranch }}
          AMPLIFY_PROJECT_REPO: ${{ secrets.AMPLIFY_PROJECT_REPO }}
          AWS_ACCESS_KEY_ID: ${{ secrets.ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.SECRET_ACCESS_KEY }}
          AWS_PROFILE: ${{ secrets.AWS_PROFILE }}
          GH_USERNAME: ${{ secrets.GH_USERNAME }}
          GH_USER_PAT: ${{ secrets.GH_USER_PAT }}
          TELEGRAM_BOT_TOKEN: ${{ secrets.TELEGRAM_BOT_TOKEN }}
          TELEGRAM_CHAT_ID: ${{ secrets.TELEGRAM_CHAT_ID }}

action.yml

Additional Resources / Info

Made by

Simone AgostinelliFollow

Alessandro AnniniFollow

Side projects will save the world. Or at least the day.

Replace Redux with React Hooks, the easy way.

Alessandro Annini — Tue, 26 Nov 2019 13:41:43 +0000

Photo by Omer Rana on Unsplash

Do you ever wonder if you can really replace Redux with React Hooks when it comes to the global state management of your applications, even the most complex?
It happens to me all the time I need to store some data so I decided not to wait a super-definitive opinion from the community but try firsthand.

What the hell, I should try anyway if it fits the way I work!

I love using GraphQL but, when I develop a complex application, I still need some kind of global store, so I started searching for articles about how to replace redux store with the useContext React hook. I found a few, this one is very inspiring but I want it to be even cleaner.

The solution I want has to be:

🎣 using React hooks;
🚫 without switch statements;
😌 damn simple and clean;
🚀 damn fast to use;
♻️ reusable.

TLDR; This is what I got:

Woah Slow Down

Step 0

When I create the Store with Store.js i need the initialState and the reducers, the latter has to be defined as a single object where every single property is a reducer function:

Then createStoreProvider high order function returns another function that has, as only parameter, the inner component for the Store provider so that you can nest in that point the components that will have access to the global state.

Step 1

The body of the second function sets up a way to retrieve and use the right reducer function from the initial reducers object and uses it with the useReducer React hook so that every action will change the global state in its own way:

Step 2

The store context that we will use as global state will now be used as context provider; it will provides an object with 2 properties: the global state itself and a function that we will use to change the state:

And that’s it.
Github gist.

Step 3 (use it!)

When we want to use the state in a component we only need to import the created Store and read the needed property with the help of the useContext React hook:

Destructuring the store context we can access to both the current state and the dispatch function that can be used to send changes to our store selecting

what to change thanks to the action type property and
how to change state thanks to the payload property just like we used to do in redux.

⚠️ Downsides

When creating React context as global store you have to be aware that every time you update a value in the store, this will re-render every component that uses it, and this could create a huge performance problem!

Solutions

This one is the cleaner: use multiple contexts so when you update one only the components that are actually using values from that store will re-render
Use useMemo React hook, this way, you can specify, for every component using the global store, on which property change it will react. I updated the previous example for this solution:

Conclusions

I like the way it all blends in my code, it’s easy to manage, it does not need updates until I say so. It’s easy enough to rewrite if you are offline camping alone in a forest.

Redux principles are still valid with this setup:

✅ Single source of truth
✅ State is read-only
✅ Changes are made with pure functions

It is true that Redux has more plugins and tools but at the end of the day I think that having a simple code in the first place is the best way to start off a new project and understand what happens when it runs.

If you want a readymade, working solution for a global store using React hooks you can take a look to the following projects:

jhonnymichel / react-hookstore

A state management library for react using the bleeding edge hooks feature

forsigner / stamen

A React state management library based on Hooks

ice-lab / icestore

🌲 Simple and friendly state for React

🙏 Thanks to Full-Staks Magazine for helping me out with downsides!

About Me

I’m Alessandro Annini, I work at Scriby.it, my own company, offering software development and consulting services.

Originally posted on Medium

DEV Community: Alessandro Annini

AI Writes Better Code When You Stop Thinking in Code

From Code to Concept

The Problem With Code-First AI

The Shift: Map-First, Code-Later

Why This Matters

What is LayeredDSL?

Why It Works: Design Goals

The Core Structure of LayeredDSL

Human + AI Cycle: Define → Validate → Generate

Define

Validate

Generate

The “One Rule”

Examples: Real-World DSL in Action

AI Prompt Engineering for DSL

🧠 Final Thought

👨🏻‍💻 About the Author

Lightning-Fast Development with Zed and Dev Containers

What’s a Dev Container?

Why Should You Care?

Enter Zed Tasks

Setup Dev Containers + Zed Tasks

Understanding Container Lifecycle Commands

Pro Tips

Conclusion

What’s my AGI again? Implementing an Autonomous Agent in Js

It is able to reason

It is able to use tools

Introspection

The Agent

Coding the agent

Conclusion

PUSHARD Progressively deploy commits between AWS Amplify environments

My Workflow

nautes-tech / pushard

Progressively deploy commits between AWS Amplify environments

PUSHARD Progressively deploy commits between AWS Amplify environments

Description

Submission Category:

Yaml File or Link to Code

Additional Resources / Info

Simone AgostinelliFollow

Alessandro AnniniFollow

Replace Redux with React Hooks, the easy way.

TLDR; This is what I got:

Woah Slow Down

Step 0

Step 1

Step 2

Step 3 (use it!)

⚠️ Downsides

Solutions

Conclusions

jhonnymichel / react-hookstore

A state management library for react using the bleeding edge hooks feature

forsigner / stamen

A React state management library based on Hooks

ice-lab / icestore

🌲 Simple and friendly state for React

About Me

Replace Redux with React Hooks, the easy way. | by Alessandro Annini | Medium

Alessandro Annini ・ Apr 22, 2021 ・ Medium

Alessandro Annini ・ Apr 22, 2021 ・
Medium