Hello @aeneasr,

I've seen that you've been busy lately and since me and my team are using this library quite a lot I'd like to help you maintaining it, reviewing some PR's with bug fixes, issues, release patches and so on, let me know if you're okay with that.

This work is not ready yet. I am just opening PR for convenience so that you can see my changes and have a chance to react. This of course has to do with #553 Right now I went with creating slate-next. The idea is to either at the end delete old slate and rename this back to slate. That is of course if we manage to make it work with old documents.

@inyono @Knorrke @arekkas think about layout editing user experience and technical details until next monday (30.5.). The proposal should include:

• How layout blocks are created (add a new video)
• How layout blocks are transformed (moved in position, transformed in number of columns)
• How do text fields behave inside of a layout block

You can also think about technical details like:

• What does the layout state look like?
• How would you deal with undo/redo
• ...

Hi guys, this is all about the #555. Namely the background plugin. It's rather big so I figured a video would help you understand what it's all about, Enjoy! :) 🎥 https://screencast-o-matic.com/watch/cFjDlgq2HI 🎥

I am unable to drop in the background layout plugin (all content plugins can be added no problem). I wanted to run this past you @macrozone, maybe you can reproduce easily. I'll do more digging if it works for you fine but I think you might have changed something around layout plugins that might be causing this.

Describe the bug use autoform to edit plugin alway throw error 'TypeError: Cannot read property 'properties' of undefined' when calling JSONSchemaBridge.getSubfields

To Reproduce react: 17.0.2 @react-page/editor: 2.2.6 @react-page/plugns-video:2.2.6

step-1: add video plugin to page step-2: edit video plugin

I find the issue caused by incompatible with [email protected]

Describe the bug The performance of the initial rendering of various editor modes seems to significantly differ. By initial rendering I mean the moment a user switches between modes using the toolbar.

According to our observations and some measurements, the winner, interestingly enough, is the "edit" mode, while the absolute loser is, interestingly enough, the "resize" mode.

We clearly notice the difference with some huge pages we have here in our internal app, which has a bunch of custom plugins. So to rule out the plugin interference, I'll try to demonstrate using a standard example page.

The measurements show that the difference in performance is not caused by how long it takes for the component tree to reconcile (render), but how long it takes to commit it, which seems to be a function of the number of state altering side effects.

The best way to demonstrate the problem is by using the Timings feature of the Performance tab of Chrome Dev Tools. It uses the Timing API which was removed from the latest versions of React, so in order to reproduce the attached measurements you'll need to downgrade your React to 16.x (I used 16.14).

In the below screenshots I'm using cellSpacing example and simply switching between editor modes. It makes a difference which mode you are switching from, so I took all measurements switching from "preview" to the target mode. When measuring "preview" performance I was switching from "edit".

I have some Chrome plugins enabled, so absolute numbers are useless. However, when compared to each other they seem to make sense. The reconciliation phase is about the same in all the measurements, but the commit phase differs greatly.

The "edit" mode is the only one that doesn't seem to have any state altering side effects. Here is the graph for it:

"Insert" and "preview" modes seem to be about 50% slower, most likely because of some state altering side effect (cascading update warning):

The "move" mode is usually about 2 times slower, again with the cascading update warning:

And here's our champ, the "resize" mode:

It's usually 10-15 times slower than "edit"! It shows the same mammoth number regardless of whether you enter or exit it. The more plugins you have on the page, the bigger hit the "resize" mode sluggishness is going to take. Here is what we see in our case on a huge page with lots of plugins:

Another way to look at it is using a more standard React DevTools profiler. For 17+ React it is the only option. It lacks the cascading update warning, it doesn't clearly show you the time it took to perform the final stages of the commit, but you can tell the unhealthy cycle by the number of commits.

cellSpacing example page shows the difference of about 3x times more commits for "preview to resize" switch than "preview to edit" switch. This is a large number, but it's not that staggering. In our application, on a page with 120 plugins we have this:

Switching from "preview" to "edit":

And here is switching from "preview" to "resize":

It looks like a bunch of state altering size effects somewhere in or around ResizableRowCell component.

Expected behavior Resize mode clearly needs fixing, but it would be nice get rid of cascading update warnings across the board.

Hey @macrozone , I see you are doing quite a lot of good work on the lib! Very happy to see that. While updating to the latest version, I've noticed a few small issues and since I am not currently set up with code, I thought I'd run it past you and you can fix in one of your many releases :)

It all has to do with background plugin: Here https://github.com/react-page/react-page/blob/master/packages/plugins/layout/background/src/Controls/BackgroundDefaultControls.tsx#L147 it should be changed from "onDragEnd" to "onChangeCommit", same here https://github.com/react-page/react-page/blob/master/packages/plugins/layout/background/src/Controls/BackgroundDefaultControls.tsx#L127.

Then here: https://github.com/react-page/react-page/blob/master/packages/plugins/layout/background/src/Component/index.tsx#L120 the state should be passed in along with the props, otherwise the preview functionality for darken and lighten stops working. This was previously handled by rendering the renderer in Controls like so: https://github.com/react-page/react-page/blob/857b80ac769af74fe8145ba3e19c05bebc8ae541/packages/plugins/layout/background/src/Controls/BackgroundDefaultControls.tsx#L56. But at some point, it was changed thus breaking the preview functionality.

Carry on with the great work! I especially love the react-dnd update, that was kicking my ass for a while. Cheers

Proposed changes

Updated dependencies @material-ui/core to 4.3.0 @material-ui/icons to 4.2.1 @material-ui/styles to 4.3.0 react and react-dom to 16.8.6

Fixed issues caused by update mentioned in https://material-ui.com/de/guides/migration-v3/:

• MaterialUI Slider moved from lab to core for example.
• removed useNextVariants
• createGenerateClassName moved from core/styles to styles

Updated also all peerDependencies of all packages.

Types of changes

• [ ] Bugfix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [x] Breaking change (fix or feature that would cause existing functionality to not work as expected) (To avoid dependency problems caused of new React and MaterialUI versions.)

Checklist

• [x] Lint and unit tests pass locally with my changes
• [ ] I have added tests that prove my fix is effective or that my feature works (nothing to test)
• [ ] I have added necessary documentation (not appropriate)
• [ ] Any dependent changes have been merged and published in downstream modules

Closing issues

closes #693 maybe also #660

ideas:

• [ ] remove material ui or wait until version 2 is out (hopefully more leightweight)
• [ ] check if postcss is really being used and if not remove it @inyono
• [ ] introduce a lightweight renderer that has zero dependencies

Is your feature request related to a problem? Please describe. I have created some plugins based on the slate plugin but wrapped in a component. An example for such a component could be an existing headline compontent with a property for different themes like "Title", "Sub", "Minor", ... you name it. Slate will get the global styling from this parent component, but also allow to use the hover buttons to add a link or underline a certain part. In the toolbar you will find the controls for the headline component properties like "theme".

My solution is working but:

• I have to use some parts of the slate plugin, which are not officialy exported. Like: '@react-page/plugins-slate/lib/serialization/createInitialState' or '@react-page/plugins-slate/lib/types/component'
• I had to replace/extend the (un-)serialization to handle also the states for the parent component properties
• I don't get TypeScript to accept my plugin type, maybe because of missing SerializationFunctions in my component?

Is there a nicer way to get this to work? Should the create-plugin-materialui provide factories to build own plugins based on slate?

Additional context Here my example code. I removed/skipped some parts (properties, type definitions, defaults, ...) to keep it short: Plugin:

import React from 'react';
import { lazyLoad } from '@react-page/core';
import SlatePlugin from '@react-page/plugins-slate';
import createInitialState from '@react-page/plugins-slate/lib/serialization/createInitialState';
import { SlateProps } from '@react-page/plugins-slate/lib/types/component';
import Component from '@react-page/plugins-slate/lib/Component';

import { serialize, unserialize } from '../../utils/slate';
import { hoverPlugins } from '../../utils/HoverToolbar';

import { defaultHeadingState } from './default/state';
import HeadingRenderer from './Renderer';

const TitleIcon = lazyLoad(() => import('@material-ui/icons/Title'));
const HeadingControls = lazyLoad(() => import('./Controls'));

const slate = SlatePlugin();

const Heading = {
  ...slate,
  Component: (props: SlateProps) => (
    <Component
      Renderer={HeadingRenderer}
      Controls={HeadingControls}
      plugins={hoverPlugins}
      serializeFunctions={{}}
      {...props}
    />
  ),
  name: 'teamshirts/content/heading',
  version: '0.0.1',
  IconComponent: <TitleIcon />,
  text: 'Heading',
  description: 'Show a Headline',
  createInitialState: () => ({
    ...createInitialState(),
    ...defaultHeadingState,
  }),
  serialize: serialize(slate.serialize),
  unserialize: unserialize(slate.unserialize),
};

export default Heading;

Renderer:

import React, { FunctionComponent } from 'react';
import Renderer from '@react-page/plugins-slate/lib/Renderer';
import Heading from '@teamshirts/components.heading';

import { HeadingControlsProps } from '../types/controls';

const HeadingRenderer: FunctionComponent<HeadingControlsProps> = props => {
  const { state, plugins } = props;

  const { theme } = state;

  return (
    <Heading
      theme={theme}
    >
      <Renderer state={state} plugins={plugins} />
    </Heading>
  );
};

export default HeadingRenderer;

Controls:

import React, { FunctionComponent } from 'react';
import { Editor } from 'slate-react';
import { BottomToolbar } from '@react-page/ui';
import FormControl from '@material-ui/core/FormControl/FormControl';
import InputLabel from '@material-ui/core/InputLabel/InputLabel';
import Select from '@material-ui/core/Select/Select';
import Input from '@material-ui/core/Input/Input';
import MenuItem from '@material-ui/core/MenuItem/MenuItem';
import FormControlLabel from '@material-ui/core/FormControlLabel/FormControlLabel';
import Switch from '@material-ui/core/Switch/Switch';
import { withStyles } from '@material-ui/styles';
import Heading from '@teamshirts/components.heading';

import { darkTheme } from '../../../../../../config/theme';
import { bottomToolbarStyles, handleChange } from '../../../utils/component';
import LeaderInput from '../../../controls/LeaderInput';
import TrailerInput from '../../../controls/TrailerInput';
import { HeadingControlsProps } from '../types/controls';

const themes = [
  'title',
  'sub',
  'minor',
];

const HeadingControls: FunctionComponent<HeadingControlsProps> = props => {
  const { state, onChange, focused, readOnly, plugins, classes } = props;

  const {
    editorState,
    theme,
  } = state;

  const onStateChange = ({ value }) =>
    onChange({ ...state, editorState: value });

  return (
    <div>
      <Heading
        theme={theme}
      >
        <Editor
          onChange={onStateChange}
          readOnly={Boolean(readOnly)}
          className="ory-plugins-content-slate-container"
          value={editorState}
          plugins={plugins}
          placeholder="Your Headline here ..."
        />
      </Heading>
      {readOnly ? null : (
        <BottomToolbar open={focused} theme={darkTheme}>
          <FormControl className={classes.formControl}>
            <InputLabel htmlFor="theme-helper">Theme</InputLabel>
            <Select
              name="theme"
              value={theme || 'title'}
              onChange={event => handleChange(event, onChange)}
              input={<Input name="theme" id="theme-helper" />}
            >
              {themes.map(themeItem => (
                <MenuItem value={themeItem} key={themeItem}>
                  {themeItem}
                </MenuItem>
              ))}
            </Select>
          </FormControl>
        </BottomToolbar>
      )}
    </div>
  );
};

export default withStyles(bottomToolbarStyles)(HeadingControls);

Bumps qs from 6.5.2 to 6.5.3.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps decode-uri-component from 0.2.0 to 0.2.2.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Describe the bug I wanted to build a sample project with vite and react-page, but as soon as I integrate the editor component it fails with:

Uncaught SyntaxError: Export 'import_react3' is not defined in module (at chunk-MDNT3GH3.js?v=c8b68aaf:17613:3)

To Reproduce

1. Check out this sample: https://github.com/Squidex/squidex-samples/tree/compose-sample/jscript/react/sample-compose
2. Start it with npm i && npm run dev
3. Goto http://127.0.0.1:5173/editor

Expected behavior A clear and concise description of what you expected to happen.

Screenshots If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: Windows
• Browser Chrome
• Version [e.g. 22]

Vite 3.2.3 and React 17.0.1, React-Page Editor: 5.2.0

Is your feature request related to a problem? Please describe.

Hello, I'm looking to find an elegant way of checking if all plugins have their required data fulfilled on submit.

Let's look at the following example:

const myFirstcellPlugin: CellPlugin<Data> = {
  Renderer: ({ data }) => (
    <SomeCustomComponent title={data.title} />
  ),
  id: 'myFirstCellPlugin',
  title: 'My first cell plugin',
  description: 'My first cell plugin just displays a title',
  version: 1,
  controls: {
    type: 'autoform',
    schema: {
      properties: {
        title: {
          type: 'string',
          default: 'someDefaultValue',
        },
      },
      required: ['title'],
    },
  },
};

I want on submit to receive an error that the title is empty.

Describe the solution you'd like

Maybe some hook that returns all errors from the plugins?

Bumps loader-utils from 2.0.0 to 2.0.4.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Is your feature request related to a problem? Please describe.

I am looking to group blocks by type on the Plugin Drawer UI component, for instance, I have layout related blocks and components relatedo to crypto, I wanted to customize the way the plugin list is displayed and also add checkboxes to filter by type on the search bar.

Describe the solution you'd like

The best way it would be allow to costumize the plugin drawer component with a custom render component for search and another to list the plugins,

Describe alternatives you've considered

The easy way just allow to override the plugin drawer component.