Replies: 10 comments 17 replies
-
|
I also temporarily pushed the changes into |
Beta Was this translation helpful? Give feedback.
-
|
Thanks! I'll take a look. |
Beta Was this translation helpful? Give feedback.
-
|
The problem was that I'm pushing the fix to the branch. |
Beta Was this translation helpful? Give feedback.
-
|
Interesting, I must have missed it while fixing circular dependency issues. I'll pull the changes and run tests once this is pushed. Thanks. |
Beta Was this translation helpful? Give feedback.
-
|
I was thinking about
|
Beta Was this translation helpful? Give feedback.
-
|
Oh I just understood what you meant. You meant something like below as per previous discussion, correct?
Either way, I am positive. I will apply those changes once the common package is done. Thanks, |
Beta Was this translation helpful? Give feedback.
-
|
The commit has been pushed. I've moved Indeed, let's start with:
Following plugins have
Not sure which of these third-party deps are tree-shakeable. Which could be kept in |
Beta Was this translation helpful? Give feedback.
-
|
This is great! However, about the So now that the common module is done, which package would you suggest to start with next? If we start with On a different topic, I saw the collaborative editing in the todo list for V1 which is great. Do you still have plans to support collaborative editing? If so we can keep that in mind for the new API and we can start supporting it in the new release. Please let me know your ideas, I'd like to hear them. |
Beta Was this translation helpful? Give feedback.
-
|
Great suggestion, let's put the preview in Extracting all the components slate-plugins-components(-fluent) is good next step. As for the collaborative editing, it's still in the roadmap, not necessarily for V1, but that would be great! |
Beta Was this translation helpful? Give feedback.
-
|
Fantastic! I'll start the modularisation of |
Beta Was this translation helpful? Give feedback.
-
|
@MikeAliG Let me know when you take a break so I can work on this in my free time |
Beta Was this translation helpful? Give feedback.
-
|
Hello! I hope you are well. Thank you very much for your wait and sorry if I took a lot of time to process the code, but please feel free to change/work any part that I'm working on, I am totally open to that and in fact I would thank you a lot as well. As for the new API, I've been trying to understand the underlying issues (if they rise) but I just pushed a small commit about the new design of
import React, { useMemo, useState } from "react";
import { createEditor, Node } from "slate";
import { withHistory } from "slate-history";
import { Slate, withReact } from "slate-react";
import {
ParagraphPlugin,
BoldPlugin,
EditablePlugins,
ItalicPlugin,
UnderlinePlugin,
pipe,
} from "@udecode/slate-plugins";
import { useSlatePlugins } from "@udecode/slate-plugins-components";
export const Editor = () => {
const { editor, editorValue, plugins, setEditorValue } = useSlatePlugins({
plugins: [
ParagraphPlugin(),
BoldPlugin(),
ItalicPlugin(),
UnderlinePlugin(),
],
withPlugins: [withReact, withHistory],
initialValue: [
{
type: options.p.type,
children: [
{
text: "This text is bold, italic and underlined.",
[options.bold.type]: true,
[options.italic.type]: true,
[options.underline.type]: true,
},
],
},
],
});
return (
<Slate
editor={editor}
value={editorValue}
onChange={(newval) => setEditorValue(newval as SlateDocument)}
>
<EditablePlugins plugins={plugins} placeholder="Enter some text..." />
</Slate>
);
};
So right now, I am working to make all the basic elements renderless to be able to test these theories and do some benchmarking to make sure that nothing is being lost and everything is behaving perfectly but as it might take some time, please let me know if you want me to work on some other parts or if you want to change anything in any part, I will gladly change it. As always thank you for your attention, and please feel free to not only let me know about your ideas but also please change/work on any part, it will help me as well. Many thanks, |
Beta Was this translation helpful? Give feedback.
-
|
I am currently transferring the components
export const ParagraphPlugin = (
// These options would be required because they should receive the component:
options: ParagraphPluginOptions
): SlatePlugin => ({
renderElement: renderElementParagraph(options),
deserialize: deserializeParagraph(options),
onKeyDown: getOnHotkeyToggleNodeTypeDefault({
key: 'p',
defaultOptions: DEFAULTS_PARAGRAPH,
options,
}),
});
where options receive: export interface RenderNodeOptions
extends RootProps<RenderNodePropsOptions>,
HotkeyOptions {
/**
* Type of the node.
*/
type?: string;
/**
* React component of the node.
*/
// In this approach this option would be required in here.
component: React.ElementType;
}
Both are possible with their own advantages and disadvantages but please let me know your ideas on this, which one would you prefer? |
Beta Was this translation helpful? Give feedback.
-
|
Ok, I think the multiple editor issue is solved. I've pushed the code into the import { useEffect, useMemo, useState } from 'react';
import { pipe } from '@udecode/slate-plugins-core';
import type { UseSlatePluginsOptionType } from './types';
import { slatePluginStore } from '.';
/**
* @description This plugin is the base of your Editor, you can dynamically change the contents as you wish and internally, it will be automatically reflected on your editor
* @see @todo LINK TO THE DOCS PAGE
* @requires key
* @param options UseSlatePluginsOptionType
*/
export const useSlatePlugins = (options: UseSlatePluginsOptionType) => {
/**
* @description This will allow component level store with fallback which allows multiple editor compositions.
*/
const [
{
editor: stateEditor,
withPlugins,
plugins,
setComponents,
setWithPlugins,
setEditor,
setPlugins,
},
] = useState(() => slatePluginStore());
useEffect(() => {
if (options.editor) setEditor(options.editor);
if (options.components) setComponents(options.components);
if (options.withPlugins) setWithPlugins(options.withPlugins);
if (options.plugins) setPlugins(options.plugins);
}, [
options.editor,
options.components,
options.withPlugins,
options.plugins,
]);
const [editorValue, setEditorValue] = useState(options.initialValue);
const editor = useMemo(() => pipe(stateEditor(), ...withPlugins), []);
return {
editor,
withPlugins,
plugins,
setComponents,
setWithPlugins,
setEditor,
setPlugins,
editorValue,
setEditorValue,
};
};Although, I put the Please let me know about your thoughts and ideas as well. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, will review this and PR some ideas |
Beta Was this translation helpful? Give feedback.
-
|
I noticed in your example you set Ideally you are able to set |
Beta Was this translation helpful? Give feedback.
-
|
Good to know! I was thinking that we can maybe save the history, reset the editor reference ( |
Beta Was this translation helpful? Give feedback.
-
|
@zbeyens I got plugins with dependencies to work with my hook but I had to be a bit clever. I know this may not be immediately relevant to you since your plugins seem to be fairly static but I think once you or your library consumes start building plugins which use state or data from apis then this dependency issue is fairly challenging to deal with. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the follow ups and PR. So, now, I think we can move on to
I have some ideas but please challenge them: Now that we have a global store, we can share the same store with the end user so that they can even modify it to their needs and overwrite the store values if they wish to do so. In which case, we don't need the /**
* Enables support for paragraphs.
*/
export const ParagraphPlugin = (): SlatePlugin => {
const {
main: {
components: { p },
},
} = useSlatePluginsStore();
return({
renderElement: renderElementParagraph(p),
deserialize: deserializeParagraph(p),
onKeyDown: getOnHotkeyToggleNodeTypeDefault({
key: 'p',
defaultOptions: p.DEFAULTS_PARAGRAPH,
}),
})};So now, if they need to change To summarise, this approach has some Pros:
*As for the on-the-fly editors, I mean the editors which the plugins need to change on-the-fly. An example of this would be the environment we need for the interactive docs where users can play around with the editor and write code to reflect the options. Although these are fine, but please let me know if you have any thoughts on any of this. I'd like to know your thoughts. |
Beta Was this translation helpful? Give feedback.
-
|
Looks to be a cleaner approach to me! This has also some cons:
Next steps:
Thoughts:
|
Beta Was this translation helpful? Give feedback.
-
|
That's great! I agree with all of them. I'll start using separate selectors as my main task. I will keep you updated. |
Beta Was this translation helpful? Give feedback.
-
|
@MikeAliG I'm currently working on this branch, I'll keep you updated! |
Beta Was this translation helpful? Give feedback.
-
|
@MikeAliG v1 alpha is released, completing all the requested features and even more! See the sandbox. I still need to write the migration guide and new docs. |
Beta Was this translation helpful? Give feedback.
-
Progress discussion #363
Hello, I hope you are well and Happy New Year. First of all, Thank you for waiting for the transition modules (
@udecode/slate-plugins-commonand@udecode/slate-plugins-test-utils) the work was taking a toll and thankfully over the Christmas I have some time to go over the transition. As for the progress, we have had great progress specially in terms of compartmentalisation and module control and it is almost ready for the initial commit but there's a problem with the new module build and I dug down into it but to no avail. The built files in the@udecode/slate-plugins-commonand@udecode/slate-plugins-test-utilsand their types are moved in a subfolder with the package name which you can find below:This issue could be on the rollup for which I found the closest issue in here which is still open but what's interesting is the problem doesn't occur for none of the other packages and it just happens to happen for the new packages (
@udecode/slate-plugins-commonand@udecode/slate-plugins-test-utils) which is probably something I'm missing but I checked therollup.config.jsand the config seems fine but I have no idea this issue occurs so please let me know if you have any solution to this issue.Have a great day,
Ali
Beta Was this translation helpful? Give feedback.
All reactions