I've built a renderer for the filesystem.

[ranfdev]

Introduction

This may seem the dumbest thing possible to implement in SolidJS, but bear with me for a second.
I'm building a static site generator (SSG), but with a native GUI (GTK4), an integrated text editor, browser preview, and everything needed to actually build a blog.
This is how I ended up using JSX to describe and render the output files to the file system.

Interactive output generation

As you probably already know, a SSG takes some files as inputs and generates some files as outputs.
My SSG is capable of monitoring the filesystem for changes and re-generating only the dependent output files.
This has been implemented thanks to the awesome SolidJS reactive primitives and some code on top to monitor changes to the file system.

Describing the output

Here comes the absurd thing. I'm using JSX to describe the output folder. Here's a simplified snippet of code:

const fsDesc = <>
  <File path="index.html">{renderedIndex()}</File>
  <CopyDir
      dir={ssgState.themeDirectory.get_child("static")}
    />
  <Dir path="blog">
    <For each={articles()}>
      {(a) => <File path={a.title}>{renderArticleContent(a)}</File>}
    </For>
  </Dir>
</>;
renderFs(fsDesc, ssgState.buildDirectory)

Let's say the user creates a new article. articles() is just a SolidJS signal, so For will receive the signal change and will render a new File.
A File simply takes the content inside props.children and writes it to the filesystem.

Abstracting the file system

I needed a specific primitive, <Overlay over={...}>...</Overlay> to prioritize some file sources.
If a file is inside the over property of overlay, that file will overwrite the one inside the Overlay's children:

<Overlay over={<File path="x">User specified value</File>}
  <File path="x">Default value</File>
</Overlay>

The overlay must also work for multiple files and entire directories. It should work transparently.
This means I needed a way to abstract the entire file system.
To do so, renderFs() creates a SolidJS Context, containing a file system implementation:

export function renderFs(tree, dir) {
  return createRoot(() => {
    <FSContext.Provider value={GioFS(dir)}>{tree()}</FSContext.Provider>;
  });
}

A File or Dir will then use the file system implementation provided by the value of FSContext:

function File(props) {
  // ...
  const fs = useContext(FSContext);
  fs.replace(props.path, props.children);
  // ...
}

The Overlay primitive is just a component which provides custom file system implementations for its children.

function Overlay(props) {
  // Create two file system implementations, overFs and underFs. The write requests to overFs will always execute, the ones inside
  // underFs get placed somewhere else when the written file is already controlled by overFs.
  // More checks are done in the real implementation...
  return (
    <>
      <FSContext.Provider value={overFs}>{props.over}</FSContext.Provider>
      <FSContext.Provider value={underFs}>{props.children}</FSContext.Provider>
    </>
  );
}

Conclusions

In my implementation, every file system operation is async. But if multiple render request happen at the same time I don't know what happens. I still need to work on this.
In any case, I'm kinda impressed with SolidJS. Its reactive primitives are pretty great and combined with JSX rendering, it's possible to describe any kind of "reactive tree" data structure. In fact, I like to think about Solid's JSX as a "syntax to describe reactive trees".

Anyway.
Build stuff and have fun.

[trusktr]

That's actually not absurd, but pretty cool! A declarative markup like HTML or JSX can represent any tree with nodes that have single parents and multiple children really well (symlinks can be like mentions of other elements by id via attributes (f.e. <symlink to="#realFile"> where #realFile is a selector similar to HTML/SVG map/use, or in JSX it could be a ref of some sort).

So this is pretty sweet! It could be useful for example for bootstrapping projects from templates, etc.