jsonkao/jasons-cms

A collaborative editor for stories that are both written and coded

jasons-cms.vercel.app

Setup

This repo uses npm.

Developing

npm run dev

Requires a .env with a LIVEBLOCKS_SECRET_KEY and a LIVEBLOCKS_PUBLIC_KEY.

Structure

The main app provides code editing functionality for the Svelte components. Inside a WebContainer, the code editor runs a dev server for the inner app ./text-editor, which provides text editing functionality.

Demos

The first live demo of Jason's CMS was released on YouTube on January 22, 2024 (watch it here). A developer update was released on YouTube later that day (watch it here). A second developer update was released on YouTube on January 24, 2024 (watch it here). A third developer update was released on YouTube on January 25, 2024 (watch it here). A fourth developer update was released on YouTube on January 29, 2024 (watch it here). A fifth developer update was released on YouTube on February 3, 2024 (watch it here). A sixth developer update was released on YouTube on February 9, 2024 (watch it here).

People who have said this is cool

• M(G)G
• UU
• AF
• IH
• AT
• C(B)O(J)
• HM

jasons-cms's Issues

Block creation, deletion, and reordering of graphics

Insertion algorithm

• Block creation works, but undo/redo is buggy

• Block insertion is buggy and shifts around text before.

When inserting a coding area:

1. We can assume it was in an empty paragraph node. Create two Y.XmlFragments, one for the XmlElements before the empty paragraph and one for those after.

• The case where there are no nodes before or after: Instead of inserting an empty Y.XmlFragment, populate it with a new Y.XmlElement with an empty Y.Text inside. That way, we can always tab into text blocks.

2. Create a new coding block.

3. In one transaction, delete the text block, and insert the three elements (the coding block sandwiched between the two new text blocks).

Deletion algorithm

• Blocks have to be able to be deleted.

1. On block deletion, create a new text block out of the text blocks before and after the coding block.

2. In one transaction, delete the coding block, then insert the new
   text block at the same place.

Minimap

• A UI/minimap for the story.

1. Every time code is saved: text-editor (via HMR on global vite:afterUpdate callback) will send back clientHeight of every graphic block (maybe wait one second to account for layout shift?).

2. Upon receiving this message, code-editor will render a minimap. Graphic icons are sized based on clientHeight. Text icons are just two lines: a div's top and bottom borders.

3. The minimap is inset in the top right of the code editor.

Tbh, why build a mirror of the thing that's right in front of you? Could every graphic have a hover floating menu with Delete and Focus options?

Also, don't use the word "graphic". Aim to introduce zero jargon. Instead, use intuitive/action-based language like "code here", coding areas, coding playground, areas to code in, area for coding

Now that we don't need git to collaborate, what about tags/commits and branching?

There could be forking. But then no merging back into main.

A database

UI for saving and going to hidden text blocks

• UI for saving

• Tab is a bit unintuitive for editing between two coding blocks.

Crossplatform install for inside webcontainer

https://esbuild.github.io/getting-started/#simultaneous-platforms

Tabs

Could probably implement manually, and key codeContent store by filename rather than graphic name

Editable graphic text

An important pro of ArchieML is that you can write graphic copy without coding. Potential approaches...

1. Editable text

Inside any component, surround editable copy with editable(). That function would turn any text into a collaborative Prosemirror editor (or something simpler) inside the Y.Map in that graphic's BlockMap.

editable() wouldn't take a default value (that would be too confusing for future readers of the code when the text could be completely different). It should take a key that points to a specific value in the Y.Map. The default content will always be the same, like "Write here". The key could be any string, and it's suggested that it's descriptive. Editing and moving the keys themselves will likely be impossible.

This is great and smooth. But there are some tough things:

• It might be hard to tell what is or isn't editable. There could be a special on-hover effect/label for editable text.
• Often we might need HTML, like for a <b> or a <span>. Here, we'd have to write… code inside of prose inside of code, and it's all inside of prose. Plus, if we introduce HTML, there would have to be two distinct renderings of the editable text… the code (when editing) and the output of the code (when not in focus).

2. Managing copy in a separate tab.

Inside any component, instantiate a copy object with copy(). That function would provide a panel for each graphic that contained text that would get live-passed (store updates) to the graphic component. Now, you'd probably want both text and other parameters, so this would be like recreating JSON or ArchieML.

This doesn't have to be complex. It could be another tab in the code editor, called Writing. And it doesn't have to be abstracted away — it could just be style to import a new copy.json file or something. But then you pull writers into the code editor.

Collaborative editing

• https://github.com/yjs/y-codemirror.next
• https://github.com/yjs/yjs-demos/blob/main/codemirror/codemirror.js
• https://github.com/rodcisal/sveltekit-svelt-yjs-example

Mobile cant handle webcontainer

CJ suggests using a VM in the Cloud like Code Sandbox just for mobile users.

How does Codeflow run so smoothly in the browser?

First focus should be on first *non-empty* text block

Component library for users

See shadcdn/ui

Tests with vitest

https://vitest.dev/guide/why.html

Initial prosemirror selection

• On page load, put cursor at beginning of first paragraph block
• On focus of a prosemirror editor, put cursor at beginning initially

Vite SSR stack trace error when deleting component

When I delete a component, I do something like

await graphicsToDelete.map((filename) => webcontainerInstance.fs.rm(`${GENERATED_PATH}/${filename}`))

But this results in the following Vite dev server error:

For now, I just won't delete the graphic file because it'll barely add memory usage in a normal use case.

Previewing stories on a `/preview/[slug]` route

See https://github.com/antfu/vite-plugin-remote-assets

Start requesting bundled zip before/during webcontainer boot

Share undo/redo state between code-editor and text-editor (needed for block deletion, I think)

I think this could be solved if both the iframe and parent used the same transaction origin.

But, wouldn't the undo manager also have to be saved? Maybe, send all undo and redo keystrokes through to the iframe via Postmessage api?

In dev, when doing HMR, kill the previous process while reusing the same WebContainer

See learn.nuxt.com's playground store

CodeMirror or Monaco? Nodebox/Sandpack or Webcontainers?

See https://news.ycombinator.com/item?id=30673759

U requests extensions, which would need us to have VSCode/Monaco. Maybe it won't feel clunky since we can load it in the background as the WebContainer boots.

See https://github.com/sonyarianto/sveltekit-monaco-editor/tree/main

Move blocks data from static json to Y.Array

Mobile cant handle webcontainer

CJ suggests using a VM in the Cloud like Code Sandbox just for mobile users.

In a recently released interview segment with Prismic, Rich Harris said the SvelteKit tutorial also does not work on iPhone because of memory issues.

Maybe mobile could rely on something like the Svelte REPL. It works smoothly on mobile, and has a nice Input/Output toggle.

• Since source code does not live on the file system, the REPL could also work with the existing Yjs code storage system. Server-side functions and global CSS files wouldn't apply though.