We could potentially add zoom support as well.

Hey,

wanted to take a look at the code and do some hacky prototyping. Unfortunately, the demo does not run since a few 0.x versions. I always get this:

Invalid hook call. Hooks can only be called inside of the body of a function component. This could happen for one of the following reasons:
1. You might have mismatching versions of React and the renderer (such as React DOM)
2. You might be breaking the Rules of Hooks
3. You might have more than one copy of React in the same app
See https://fb.me/react-invalid-hook-call for tips about how to debug

The error disappears when I comment out <Editor /> which may mean its related to react-slate.

Any ideas?

Thanks a bunch,
Benedikt

The issue is: It's hard to determine why one or the other is used

sx={{
  color: "#3333ee",
  bg: "muted"
}}

For certain use cases it'd be great to provide a way for users to mix in a handful of their own components to the Blocks editor. We want something that essentially "Just Works" for most components, and complex needs for users can be addressed using a custom plugin.

To start I think we should only focus on block-level custom components to keep things as simple as possible for this MVP.

The API should be simple and declarative. Perhaps something like?:

<Editor theme={theme} components={components} />

In order to work with Slate we need to handle a handful of things that are required to integrate into our implementation of the editor.

Component controls

We can leverage something like propTypes or propertyControls which determine the props that can be changed and what their dials/knobs might look like.

Depending on the amount of controls and properties allowed, we can open up the inline editor like links/images.

If there are many properties that are editable we can expose a sidebar like the theme editor.

If a component accepts children it can then be edited within as though it's the editor itself.

The output MDX will look something like:

# Hello, *world*!

<TomatoBox>

## Here's some editing

Inside our custom `TomatoBox` block!

<YouTube videoId="4fHw4GeW3EU" />

</TomatoBox>

And more stuff!

In addition to editing the components, the toolbar will need to know what components have been passed and expose them in the toolbar (perhaps in a custom component dropdown or expandable sidebar).

Commands

We'll need to be able to expose Slate commands so we can insert/toggle components that are in context for when they're clicked. Toggle will be for elements that accept children. Insert for void elements.

Rendering

In node rendering we will have to check the block type against available components and render them when relevant. If nothing exists, we return next() since there might be a plugin that handles the rendering of that node.

Serialization

This is probably the trickiest piece, but one I think that we have almost there. We have to be able to read in custom components as JSX nodes in the MDX and map them to blocks. This means that the serializer will have to know. Here's a test showing part of that functionality.

If it's not a component that it knows about, it sets it as a jsx block (for the live editor).

In addition to handling MDX => Slate schema, we need to go the other direction. This part could be a bit tricky since the serializer needs to know, ahead of time, the component block type. One potential way to do that is to add some type of private prop __BLOCKS_COMPONENT_NODE__: true with a catch all matcher at the end of the serializer.

If we end up there and the props exist we know to write out as JSX.

Schema definition

If a component is a void component we will need to specify that in Slate. Currently the schema looks like:

import { Block } from 'slate'

export default {
  document: {
    last: { type: 'paragraph' },
    normalize: (change, { code, node }) => {
      switch (code) {
        case 'last_child_type_invalid': {
          const paragraph = Block.create('paragraph')
          return change.insertNodeByKey(node.key, node.nodes.size, paragraph)
        }
        default: {
        }
      }
    }
  },

  blocks: {
    image: {
      isVoid: true
    },
    hr: {
      isVoid: true
    },
    YouTube: {
      isVoid: true
    },
    Gist: {
      isVoid: true
    }
  }
}

We will likely need to have some sort of static property in user components that we can use to extend the config. We could also potentially check in propTypes to see if children is accepted as a prop.

I think these are all the pieces we need. Am I missing anything @jxnblk?

just excited by this, is all XD

This requires us to set the theme that's passed in for the canvas and rendered blocks (which I believe we might be doing) and then handle the theme change by calling onThemeChange when the theme panel is edited.

The API would look something like the following:

<Editor
  src={myJSX}
  theme={myTheme}
  onChange={handleJSXChange}
  onThemeChange={handleThemeChange}
/>

We may need to place the rendered component into an iframe and then scale it.

I see that you guys are using Material UI icons. May I suggest Feather instead?

And, since I don't think that Feather currently has all of the icons required, I could design them (as I have designed quite a few icons for Feather recently) and then add them to Feather and then this project!

Would really love to help contribute to this project! Both this and the desktop app seem very promising!

I currently cannot get the demo to run. Gatsby compiles with a few linter warnings, but there is a runtime error in the visitLeaves function of slate-mdast-serializer:

TypeError: Cannot read property 'length' of undefined
visitLeaves
node_modules/slate-mdast-serializer/lib/index.js:84

Any idea on how to fix this?

Thanks!

When deleting components off the page, the selection state is completely lost. Something should stay selected, ideally something within the same group as a similar position in the tree.

• https://blocks-ui.com/getting-started
• https://blocks-ui.com/guides
• https://blocks-ui.com/guides/writing-a-custom-block
• https://blocks-ui.com/advanced

(also some of the advanced docs only have titles)

In order to keep things as simple as possible for the MVP let's now allow non-void JSX blocks to be placed in other JSX blocks. This creates a lot of complexity that we can avoid for the time being.

When generating the modified code to return, we need to automatically add imports for any components that may have been added. We also need to remove existing imports for those that may have been removed.

Similarly to Google Docs and Dropbox Paper it'd be great to be able to highlight text and change its color.

This will require creating a new mark type in the Slate schema which maps to a Highlight component in MDX.

It will require a few changes in the AST of MDX so that inline JSX has deterministic parsing. Currently inline JSX nodes aren't parsed with their closing tag so it's impossible to determine which open tag corresponds with which closing tag:

• mdx-js/mdx#556 (comment)
• mdx-js/mdx#556

• Docs
• Own package

See https://github.com/axe312ger/mdx-live-editor

Maybe we can join forces? :)

We're currently using slate-mdast-serializer but it likely makes sense to use our own, MDX-specific serializer. While we port the current serializer over we can ditch the leaves usage since that has been removed.

After choosing a preset (like deep), and checking the code pane, it doesn't adopt the background color so the text color doesn't have enough contrast

The padding, etc size related values are currently number inputs. It would be nice if these were step-sliders or something that

A) locked possible values to the values in the theme
B) allows switching between "in theme" and "out of theme" states (that is, using the 1st, 2nd, 3rd theme value or using 4px, 15px, 33px)

When dragging in demo components, I can click on various visual aspects of the component (such as children) however, it's hard to get an overview of what the component is.

It could be nice to add a simplified sub-tree view of the tree below the selected component that extends beyond the current simplified "children view"

We should provide basic installation and usage instructions.

Hi @johno XD

Just curious if this is something that is still in development.

Cheers,

Richard