Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Component API #2

Open
exastencil opened this issue Feb 22, 2024 · 0 comments
Open

Component API #2

exastencil opened this issue Feb 22, 2024 · 0 comments
Assignees
Labels
core A core feature new Something that needs to be built from scratch
Milestone

Comments

@exastencil
Copy link
Owner

exastencil commented Feb 22, 2024

The impetus for making Porous is to build applications that can be broken down into smaller components that are easier to reason about, similar to many frontend frameworks, but to avoid the added complexity of having a whole slew of toolchains to make an application that runs partly on the server and partly on the client. Hence, components need to build on the server and run in the browser with the same code. A goal of the project is to try and keep the way these components are defined as simple and intuitive as possible.

This is one of the core features needed to make Porous feasible.

While the ideal long-term solution is probably to write a pure ruby application, compile it to WebAssembly and run it in the browser, this will require that a layer of software be written to manipulate the DOM as needed. The simpler approach is to use the existing libraries that wrap the browser's JavaScript API so that we can write Ruby that is close to a typical frontend framework's JavaScript.

To start with I used the component architecture from Inesita, which already renders in the browser, combined with the VirtualDom Ruby (Opal) wrapper which adequately describes the HTML structure so that strings can be rendered on the server. This gives some handling of client-side interactions by wrapping browser events and APIs, and providing a way to manage some component state.

I don't know if this will suffice to build sufficiently complex application behavior, but my plan is to refactor this as I go and perhaps replace the rendering code to depend on Paggio, since it is already a dependency in Opal::Browser and that will be needed for many other features it provides.

@exastencil exastencil added the core A core feature label Feb 22, 2024
@exastencil exastencil added this to the v1.0 milestone Feb 22, 2024
@exastencil exastencil added the new Something that needs to be built from scratch label Mar 16, 2024
@exastencil exastencil self-assigned this Mar 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core A core feature new Something that needs to be built from scratch
Projects
None yet
Development

No branches or pull requests

1 participant