DEV Community: Jaine PS

𝗜 𝘄𝗲𝗻𝘁 𝘁𝗼 𝗖𝗮𝗿𝗻𝗶𝘃𝗮𝗹 𝘁𝗼 𝗽𝗮𝗿𝘁𝘆, 𝗯𝘂𝘁 𝗜 𝗰𝗮𝗺𝗲 𝗯𝗮𝗰𝗸 𝘄𝗶𝘁𝗵 𝗮 𝗦𝘁𝗮𝘁𝗲 𝗠𝗮𝗰𝗵𝗶𝗻𝗲.

Jaine PS — Tue, 02 Jun 2026 14:19:30 +0000

Carnival broke our assumptions about software.
We almost built Loopa wrong.
Not because of code, but because of assumptions.

Initially, Loopa was designed as a general circular fashion platform. But we saw a unique window to launch during Carnival, where identity shifts fast, trust is contextual, and timing is everything.

The shift from “General Circular Fashion” to “Carnival Circular Fashion Mode” wasn’t a UI change. It was an architectural validation.
Because we chose structure over speed before scale existed, our system didn’t blink.

Clothing exchanges aren’t just “status” columns.
They’re modeled as state machines, not simple CRUD flows. Each transaction moves through explicit states, with rules enforced in the service layer, never in the UI, never directly in the database.

Supabase is fully abstracted behind repositories.
Business logic lives in services.
Side effects, real-time updates and cache invalidation, run through an internal event bus.

Components don’t talk to the database. Ever.
It might look heavy for something that started with Carnival.
But when people reinvent themselves overnight, systems can’t afford to be vague.

The real MVP decision wasn’t the stack.
It was choosing structure over speed before scale existed.
Carnival is chaotic by design. Software shouldn’t be.

When have your architectural choices been the “hero” of a business pivot?

How do you handle P2P transactions?

Jaine PS — Tue, 02 Jun 2026 14:18:17 +0000

How do you handle P2P transactions when there’s no delivery system and no platform-controlled handoff?

That was the core problem behind Loopa.

Physical exchanges are messy. People change plans, meet late, ghost, or confirm things out of order. In that context, a simple status: "completed" field isn’t just naive, it’s dangerous. It creates race conditions and edge cases you only discover once trust is already broken.

I built a centralized State Machine.
Each transaction moves through explicit states with strictly defined transitions in TypeScript. There’s no “jumping ahead.” Success is gated: the system only allows it when both parties independently confirm the physical exchange. No UI shortcuts. No database flag flips.

All business rules live in state handlers, completely isolated from the Next.js App Router. Components never touch the database directly. The UI reacts, the engine decides.

By pairing this with Supabase Realtime for chat, the system stays predictable even when human behavior isn’t. The rules don't bend just because the physical meeting is chaotic.
The real lesson wasn’t about the tools. It was about designing software that assumes people are human and keeps the system's integrity intact anyway.

How are you handling "human variables" in your logic?

Repository Environments: Remote and Development in Git

Jaine PS — Mon, 08 Jan 2024 16:37:56 +0000

There are two main repository environments:

Remote environment and development environment.
The remote environment is where changes made to the computer are sent to a remote environment, and will be able to be shared.

The development environment is where the local machine is. This environment is made up of three parts: Working directory, Staging area and Local repository.
To take a remote repository and run it locally, use the command:

git clone - https://github.com/user_name/directory.git
Copying is done in two places, in the Working directory e no Local Repository. Why git is version distribution control.
The local repository is a literal copy of the remote repository, the only difference is that it is not shared.
Another thing that the command git clone does, is to create a folder that will contain this copy.

When a file is created, it is only present in your working directory, to see what is happening in the working directory, use the command:git status, that will tell you which branch you are working on.

After creating a file, it is placed in the staging area, this means that all changes that will be committed to the remote repository.

To send the changes to the staging area, use the command:

git add -file_name
To commit these changes to the local repository, use the command

git commit -m “message”

To write good commit messages

To share your changes, and send them to the remote repo, use the command:

git push
Push sends only the changes, so it is very efficient network use.

The proper use of these commands, plus the habit of writing clear and informative commit messages, contributes to an understandable history and facilitates collaboration in software development projects.

Resolving two code smells using the atomic design methodology

Jaine PS — Thu, 04 Jan 2024 12:49:16 +0000

Thinking about design system is a practice of abstracting components, transforming them into reusable components, culminating in consistent, efficient code with a high level of scalability.
That means that it's a catalog with all reusable components, it can contain information about the use of these components and how to build their interfaces.

Atomic Design is a design system pattern, which aims to start from a base element and reach a more complex element, functioning as a living system.

BASIC ➡️ COMPLEX

“We’re not designing pages, we’re designing systems of components.” — Stephen Hay

Bringing it to development, we can paraphrase it as follows:
“We’re not building pages, we’re building systems of components.”

The basic structure of Atomic design is:
ATOM: Fundamental block, it is an HTML tag, for example an input or button.
MOLECULE: It is the joining of atoms with the aim of forming a functional unit or that represents a purpose. For example: Search or Form.
ORGANISM: It is the set of molecules, the organism contains more than one responsibility but brings together molecules with the same context. For example: Header, Footer, or Side Menu.
TEMPLATE: The template organizes the layout of the page using organisms.
PAGE: The page passes the data to the template and makes the organisms interact with each other, putting the system into practice.

Atomic design promotes solid foundations that are established from the beginning, with all elements being initially planned: fonts, color palette, avatars, buttons, etc.

When developing an application, even if initially the main focus is not on expansion or increasing complexity, it is still possible that at some point the application will reach a level of complexity at which common software development problems, so-called“code smells”.

Code smells arise when a series of development decisions result in a deep problem in the code.

We will solve two code smells using the atomic design methodology.

Repetition of components or services - DRY.
When there is a change in the development team and the design pattern is not consistent, components or services may be recreated in different contexts, which overloads the code and interferes with the application's performance.

For example:

And the component:

Resolution:

The components

CommentCount

and isLikesCount are almost the same, except for the properties, they can be unified into a single molecule, which is responsible for showing the number of items and using an icon that represents that item.

Excess of cascading properties in a single component.

It's difficult to understand components with a long list of properties. Furthermore, the more branched the properties passed to the component increase the ineligibility of the code, going against the purpose of clean code.

To solve this problem, we separate the properties that use the user as a base in a molecule called Avatar, and thus build the PostComment organism.

The Atomic design methodology can be expanded to frontend as a fundamental tool when addressing common software development challenges, such as code smells. Repetition of components or services (DRY principle) and an excess of cascading properties within a single component—can be effectively resolved through the application of Atomic Design principles. In addiction, is important to understand that frontend and design needs to have a symbiotic relation.

source:
https://bootcamp.uxdesign.cc/building-design-systems-with-atomic-design-fd21e86f34c5
https://bradfrost.com/blog/post/atomic-web-design/

How the DOM and Virtual DOM Dance: A Guide to Reactive Programming in Web Development

Jaine PS — Fri, 10 Nov 2023 16:23:29 +0000

Let's delve into the fascinating world of the Document Object Model (DOM)! 😋

The DOM, short for Document Object Model, serves as a representation of the UI, whether it's composed in HTML or XML. Imagine it as a tree of tags. To interact with this structure, we employ a scripting language such as JavaScript.

Now, for the sake of performance optimization, we don't directly modify the DOM itself; instead, we work with the Virtual DOM 🥸.

But what exactly is this Virtual DOM?

It's like a reflection of the real DOM, but with HTML tags endowed with predefined functionalities. Essentially, you write HTML components and infuse logic into them through streams — a series of related events unfolding over time. Reactive programming frameworks are the magic behind the scenes, creating and managing this virtual DOM.

Welcome to the realm of the Reactive Programming paradigm!

Reactive programming thrives on the propagation of change.

In a nutshell, here's the sequence when altering the DOM:

The entire virtual DOM undergoes an update.
A comparison is made between the updated virtual DOM and its previous state.
React determines which objects have undergone changes.
Only the changed objects are updated on the real DOM.
Changes on the real DOM translate into alterations on the screen.

By combining the DOM with reactive approaches, we empower web development with dynamism. This approach allows us to handle intricate data flows and changes, resulting in interactive and responsive user interfaces.

What kind of properties can be passed across the React Native bridge?

Jaine PS — Fri, 10 Nov 2023 16:03:29 +0000

A bridge in the React Native universe is more than just a connection; is a cross-platform communication between native languages (such as Kotlin, Java, Objective-C and Swift) and the powerful JavaScript. This capability opens the door to building mobile applications efficiently and flexibly.

Before we dive into the transferable properties, it is crucial to understand the underlying mechanism that guides the flow of these properties between different platforms.

When opening any application developed in JavaScript on your mobile device, you may wonder: magic? Yes, indeed! It's the magic of React Native in action.

React Native operates through a threading model for the render pipeline, where threads represent a series of instructions executed by the CPU. In this context, three essential threads come into play: the UI thread (or main thread), the Shadow thread (or Shadow tree) and the JavaScript thread.

The UI thread, originating from the native DOM, is what creates the other two threads. The JavaScript thread manages the application logic, while the Shadow tree observes the states and implements changes to the layout. Changes to the view are calculated integratedly and, at the end of each event loop, are sent to the native side in serialized JSON format.

Thus, properties that cross over to the native side take the form of serialized JSON, restricting themselves to JSON-compatible types.

Consider the example of clicking a button. Since it is not possible to pass callbacks directly, the native side operates via events. The click event is sent, and the JavaScript triggers a callback. This callback is processed in Shadow, triggering the state change. After this change is complete, the result is serialized into JSON and sent to the other side of the bridge, thus ending the communication cycle.

In short, the React Native bridge enables the efficient transfer of properties between languages, these props should be serialized JSON, and all JSON types can be passed to native side, providing a mobile development experience marked by versatility and effectiveness.