Gestalt's journaly: Building a web framework

Updates
#1

In the spirit of keeping ourselves accountable and having a record of the steps we are taking to build the framework, we’ll be sharing updates in this journal with no particular structure.

This and past week I focused on the logic for modeling and loading targets’ routes and layouts. For example, in a project with the following structure:

target/
  routes/
    settings/
      _layout.jsx
      index.jsx
      user.jsx

_layout.jsx contains a layout that’s applied to all the routes in the same directory and nested directories. This approach takes inspiration from SvelteKit with the difference that our models are more generic to map them to different UI frameworks.

The natural next step after this is to extend the interface of renderer plugins to map Gestalt’s router to the router of the UI framework represented by the plugin.

1 Like
#2

are you considering using stuff like state machines to expose framework events to developers? not sure if that’s a good idea or not, but I find a lot of cases in which giving access to an event system helps users to create stuff easier?

#3

That’s a territory we’d like to explore and form an opinion on, but it won’t be a priority. Vue and Svelte already have reactive primitives that are more powerful that React’s because they can detect the reactive tree so we might bring some ideas from there to React. What would you suggest based on your experience?

#4

Here’s another update on the progress we’ve made in the past week.

  • Turn renderers’ hydrate and ssr logic into dynamically generated Javascript modules: Since Gestalt will use Vite, and with it Rollup, to transpile and bundle Gestalt’s projects, virtual modules are excellent building blocks upon which to build the contract between the framework and the renderers. Here’s an example of how the React renderer instructs Gestalt on how to hydrate, and how to ssr.
  • Integration tests for renderer plugins: Delivering code with the confidence of not introducing regressions is crucial to build trust with users of the frameworks and for that reason we added integration tests to the renderers (Vue & React). They assert that given a component, the hydrate and ssr modules do what we expect them to do.
  • Multiple package.json-exported modules over a single one: Our first approach to export modules from @gestaltjs/core proxies all the exports through a module that represents the public interface. While that leads to a very idiomatic API, it worsens the ergonomics when writing tests because vi.mock ends up creating mocks for all the sub-modules. To improve developer ergonomics, at the cost of making the setup slightly more cumbersome to maintain and harder to reason about, we are moving towards having many exports. Path is the first one that we’ve migrated.

What’s next

  • We are adding integration tests to the Svelte renderer.
  • We’ll add support for SSR pages and start looking into layouts. For this, we’ll need to extend the renderers’ interface to introduce the concept of router.
  • We welcomed Patricia. She’ll get involved in designing Gestalt’s identity and ensure we convey the value of the framework through its design.
  • We’ll implement the @gestaltjs/create-project package that will contain a CLI for creating Gestalt projects.

If the project sounds interesting and you’d like to get involved, you can join our Slack channel and say hi :wave: