rhlbulls

Check out Monkey Mochi an interactive, fast-paced, action-packed climbing game where you control a monkey jumping platforms, collecting bananas, and battling aliens! This game was built purely in JavaScript using the Phaser.js physics engine, with all assets crafted in Aseprite.

Link to game: https://monkey-mochi.netlify.app/

Link to repo: https://github.com/rhlbulls/monkey-climber-game

Link to assets: https://github.com/rhlbulls/monkey-climber-assets

Signals >> Hooks

Signals are a more efficient alternative to React hooks. Signals are objects with a .value property that allows for updating the value without triggering a complete re-render. This performance improvement is achieved by passing the signal object's reference instead of the actual value. Unlike hooks, signals can be used inside or outside components.

Computed Signals

@preact/signals also provides the computed(fn) function. This function can be used to compute a signal based on the values of other signals. Computed signals automatically update their values based on changes in other signals, and they are read only.

Global State Management

Signals created using signal() and computed() functions are globally accessible when exported from a function. These signals can be modified from any component. To create signals locally within a particular component, useSignal and useComputed hooks can be used.

More on Signals

I've been recently using a tool called D2 (Declarative Diagramming) for making diagrams in documentation and system architectures. Unlike tools like Figma or Lucid, which can be challenging for developers, D2 offers a straightforward syntax and the ability to convert code into diagrams.

It also provides options to turn the diagram into various UML diagrams and has built-in shapes for entities like cloud and database. The best part is that developers can easily maintain and modify diagrams through code, without dealing with complex graphical interfaces. D2 even has a VSCode extension for writing and previewing D2 files. Give it a shot in their playground. Thank me later!

Clean Architecture for .NET WebAPIs simplifies code maintainability and scalability for enterprise scale-apps. It separates the implementation into four layers, each in its own .NET project: API (Presentation), Application, Infrastructure, and Domain.

API Layer:

• Handles routes and controllers.

Application Layer:

• Manages core business logic using services from the Infrastructure layer.

Infrastructure Layer:

• Connections to databases and external services.

Domain Layer:

• Holds Entities and Classes shared by the Application and Infrastructure layers.

How do layers communicate with each other?

The API layer's controllers communicate with Command/Query Handlers through MediatR, implementing the CQRS pattern. The Application layer handles core business logic by calling services from Infrastructure layer.

The Application layer is not dependent on Infrastructure layer, meaning it cannot directly call service from the infrastructure layer. To bridge this gap, we create interfaces in the Application layer. These interfaces are then fulfilled by actual objects injected from service classes using dependency injection.

The goal of inverting control between the Application and Infrastructure layers is to decouple service implementations from the core logic. This makes the architecture more adaptable to changes in databases or services while keeping the business logic stable. The Domain layer acts as a shared space for entities used by both the Application and Infrastructure layers.

More on Clean Architecture? Watch Jason Taylor's video here

In error handling, we commonly throw exceptions to the caller function. However Exceptions have downsides.

Cons of Exceptions:

The caller doesn't know the implementation details, and handling multiple exceptions within a single code block becomes challenging.

Exceptions are best when:

You are not sure about how to manage the error, you can throw an exception and terminate the method, leave the responsibility of handling the error to the caller function.

In the Result Pattern, we no longer throw Exceptions. Instead, the service class returns a Success or Failure Result Object to the controller, containing sufficient error data. The controller can then easily transform this result object into API Response objects. The controller should be fully responsible for adding the response status code based on the Result object.

Pros of Result Pattern:

Easier to Test since we handle all possible cases.

Cons of Result Pattern:

Caller has to manually check if the operation failed.

Best implementation of Result Class on the internet! https://stackoverflow.com/a/64209416