Contribute to Observable Framework

[pearmini]

Hi there! Author of Genji here. 👋

About two weeks ago, Mike left a message on Genji's discussion asking me wether I would like to contribute to Observable Framework or not. My answer is definitely yes and I hope the invitation is still open!

Besides using Observables in the Observable runtime as Mike mentioned in the discussion, I'm also interested in adding Framework Components. Framework components are the basic building blocks of any Framework projects, which let users split the UI and logic into independent, reusable pieces. A Framework component is typically defined by a Markdown file:

<!-- RedLabel.md -->
```js
const { text } = Props.define();
```
<span class="red">${text}</span>

<style>
  .red {
    color: red;
  }
</style>

Then it can be imported from other Markdown files:

<!-- index.md -->
```js
import RedLabel from "./RedLabel.md";
```

<RedLabel>Hello Framework Components!</RedLabel>

I think this can solve some issues discussed in #971 and is close to Fil's proposal: #1043. Compared to JSX or MDX, Framework components are more Framework-like: organizing templates, styles, and logic within a Markdown file. I'm willing call it the last piece of Framework's Markdown-based architecture. Interestingly, I find that Astro does the similar thing!

How do you feel about Framework Components? If you don't think Framework Components are necessary, I would still be happy to discuss other things I can help with. Thanks for reading and thanks for building such a project with so many possibilities!

[mbostock]

Hi @pearmini! We’re very interested in expanding on Framework’s concept of components.

We are currently working on support for React (+ JSX) components in #1216. This may expand to include MDX support. Our rationale is that React is well-known, and that supporting React will make it easier for users to get started with Framework and also share code (components) between Framework and other React apps. We could potentially support other JSX-compatible frameworks such as Preact and Vue, too.

The current prototype in #1216 introduces a concept of “page loaders” which is like data loaders for generating pages (instead of data) at build time. This allows page loaders to be written in any language and allows server-side rendering #931. I’m not sure yet if we’ll stick with this design or pare it back so that it’s more opinionated and restrictive about how components are implemented. Our primary goal is to support React with server-side rendering and automatic client-side hydration, so I’d like to explore a more constrained solution first. It would be nice to have the additional flexibility, but the first priority is great support for React.

The primary challenge I see is supporting server-side rendering since Framework doesn’t currently allow user code to run at build time outside of data loaders. We’ve considered both isomorphic and server-side JavaScript fenced code blocks #234, but I’m not sure I want to favor isomorphism by default. I think it’s likely needed for components, but otherwise I like the idea of server-side rendering being more explicit and opt-in… but, perhaps, isomorphic by default is inevitable.

Another challenge is consuming the output of data loaders from server-side JavaScript. This is related to the concept of chained data loaders. #332 We consider reading data generated by a data loader during server-side rendering a requirement, which means we’ll need to know which data loaders need to run before the page can be generated and to expose an API for user code to read the output of the data loaders (likely FileAttachment). And that might mean supporting npm: imports when running user code in Node. #288 (Also, unlike client-side code, references to files don’t need to be strictly statically analyzable since this code only runs during build, which allows further flexibility.)

So, there are a lot of things tied together here to figure out! The idea of a Framework-specific component architecture is also interesting and I’d love to hear more thoughts on a novel Markdown-based component specification vs. something that already exists (MDX & JSX). Do you think a new component specification would be sufficiently better to entice people to use it? Our thinking is that compatibility with existing frameworks is higher leverage, even if it’s not as Framework-like.