Need New Maintainers

[mckenzieja]

It's becoming apparent that this repo is becoming abandoned by it's creators. And although it's mentioned that they're working on a new version, that project is apparently stale/abandoned as well.

At the moment of this writing there is 49 outstanding pull requests and no one has reviewed or offered feedback for them. It's clear that the community at large is interested in supporting this project but being ghosted by the repo owners.

@nikgraf @adrianmcli @juliankrispel @bkniffler Could we have a discussion on adding one or perhaps two more moderators to this project to get the ball rolling? I think I speak for many here that we enjoy your contributions to this project and we'd like to continue to help keep it alive.

[nikgraf]

hey @mckenzieja, absolutely happy to give new maintainers access.

There are 2 concerns from my side:

• It needs people who are not only maintaining their needs, but follow a bigger picture
• It needs trustworthy people to avoid someone coming in and sneaking in hostile code

In order to move fast quickly, but avoid any issues I propose to add at least 3 people as maintainers and any PR that receives at least 2 approvals from these 3 will be merge.
I can do npm releases initially and eventually pass on these rights to whoever stays engaged for a little while.

What do you think? Are you interested to be a maintainer?

[juliankrispel]

I 100% agree. The repository needs new maintainers. I updated the readme now to reflect that.

For full transparency: I have been looking for maintainers for a while and have had some promising involvement throughout that time but ultimately I haven't found someone who wanted to take over full maintenance and have not found the time personally to keep up involvement since my professional life has been taking me elsewhere.

Off the top of my head the first thing I can do at this point is to make this clear in the main readme, that the repository is actively looking for maintainers. I've done that now.

If there's anything else I can do to help with this please lmk I'd be happy to.

Looking forward to people getting involved, here's hoping 🙏

[Aromokeye]

Developers like me are using DraftJs because of this plugins concept. Please keep it alive. Thanks

[DaniGuardiola]

I just rewrote the whole plugin <Editor /> component in that last couple of days (wip, but I already have a bunch of plugins going on in my personal project).

This is some funny timing lol. Here's some more info:

• I used a functional component with hooks
• Attempted to preserve backwards compatibility while experimenting with some additional ideas, see below
• Added onContentChange hook (diffs the contentState inside the onChange handler) that can also be used as a debounced listener per-plugin).
• "Marked" as deprecated the initialize and willUnmount hooks as they were using unsafe and obsolete lifecycle methods. What this means is they still exist and work as intended but they show a console.warn message about the deprecation. The implementation is hacky as the lifecycle methods don't exist in functional components, but I think I managed to get it working.
• In order to somehow fill the feature void left by this deprecation I implemented a simple store system based on Immutable Map, exposing get, set and delete. The store is opt-in and per-plugin and is passed along with the pluginMethods on hooks that receive it. It is mutable and unique for each plugin / mounted Editor. It works with a similar "magic" to that of hooks, and in fact relies on the order of the plugins to keep the relationship between plugins and their stores.
• I tried to optimize performance by using useMemo and useCallback in a bunch of places, as well as useEffect.
• I created a couple of plugins with a different, more decoupled approach. I actually rewrote part of my WIP editor project with these plugins. The plugins are wordCount and muiTheme. Explanation below. BTW you can check the project in my lab. It is updated every night straight from my private repos.
• I also included a few extras using different (but structured, modular and compatible) patterns. These include hooks, components and plain function utils at the moment.

And now a quick rundown of the example plugins I created:

• wordCount: receives an onWordCountChange listener, which it fires every time the word count varies. Highly optimized.
• muiTheme: simple theming system for block and inline styles using the material-ui styling functionality.
• useFormatMenu: receives editorState and setEditorState and returns formats and toggleFormat. Handles refreshing the current selection / cursor styles (formats) and provides a way to change them (toggleFormat). Useful for implementing a format menu (duh :P).

I'm gonna be brief with the rest of them because I just realized that these have apparently been the most productive couple of days of my life and there's just too much stuff.

• useSelectionMenu: handles open / closed state for a menu that opens on selection, as well as creating a fake anchor element for positioning.
• <FormatMenu />: using useFormatMenu implements a material-ui based menu interface.
• <FloatingFormatMenu />: using useSelectionMenu and FormatMenu implements a floating format menu that opens on selection.
• makeMuiTheme: creates a hook that when used returns a CSS class name intended to be used as className in a wrapper of <Editor /> for block styles, and a customStyleMap for inline styles.

I got a bunch more things that I'm still experimenting with. All of the things I mentioned above are already working just fine in my editor project.

As you see, I've taken a particular approach to this plugin system. I tried to make it as modular, declarative, composable and extensible as possible. It is still quite easy to use if you're either a plugin developer or a plugin user, but it allows for so much more freedom and it is updated with the state-of-the-art React hooks patterns.

I plan on finishing the implementation and making some high quality plugins (prioritizing the ones I need for my editor). I'll also test it with the plugins contained in this repo to make sure it is retro-compatible, and I'll try to update some of them to test if my store implementation translates is a good idea or if I need to think things over.

Here's the entirewordCount plugin as an example:

const countWords = string => string.split(/\S+/).length - 1

export default ({ onWordCountChange }) => ({
  initialStore: {
    lastCount: null
  },
  onContentChange: function (editorState, pluginFunctions) {
    const store = pluginFunctions.getStore()
    const count = countWords(editorState.getCurrentContent().getPlainText(''))
    if (count !== store.get('lastCount')) {
      store.set('lastCount', count)
      onWordCountChange(count)
    }
  },
  options: {
    onContentChangeDebounceWait: 150,
    contentChangeOnInit: true,
    store: true
  }
})

And here's a (very) simplified example of the theme module usage:

editor-theme.js

import { makeMuiTheme } from 'draft-js-plugins'

const blockStyles = theme => ({
  paragraph: {
    marginTop: 8,
    fontSize: 16
  },
  h1: {
    fontSize: 32
  },
  h2: {
    fontSize: 26,
    marginBottom: 12
  },
  h3: {
    fontSize: 22,
    marginBottom: 10
  },

  // TODO: create h4-6 styles

  // base blockquote style
  blockquote: {
    paddingLeft: 26,
    paddingRight: 16,
    backgroundColor:
      theme.palette.type === 'dark'
        ? 'rgba(255, 255, 255, 0.08)'
        : 'rgba(0, 0, 0, 0.08)',
    borderRadius: 3,
    margin: 0
  },
  blockquoteDecoration: {
    backgroundColor:
      theme.palette.type === 'dark'
        ? 'rgba(255, 255, 255, 0.4)'
        : 'rgba(0, 0, 0, 0.4)',
    borderRadius: '3px 0 0 3px'
  },
  // blockquote that follows a blockquote
  blockquoteFollower: {
    borderTopLeftRadius: 0,
    borderTopRightRadius: 0
  },
  blockquoteFollowerDecoration: {
    borderTopLeftRadius: 0
  },
  // blockquote that is followed by a blockquote
  blockquoteFollowed: {
    borderBottomLeftRadius: 0,
    borderBottomRightRadius: 0
  },
  blockquoteFollowedDecoration: {
    borderBottomLeftRadius: 0
  }
})

const inlineStyles = theme => ({
  code: {
    background: 'red'
  }
})

export default makeMuiTheme(blockStyles, inlineStyles)

MyEditor.js

import React from 'react'

import { PluggableEditor, wordCount, muiTheme } from 'draft-js-plugins'

export default function MyEditor ({ onWordCountChange }) {
  const [editorState, setEditorState] = useState(defaultContent)

  const editorTheme = useEditorTheme()
  const plugins = [wordCount({ onWordCountChange }), muiTheme(editorTheme)]

  return (
    <PluggableEditor
      plugins={plugins}
      editorState={editorState}
      onChange={setEditorState}
    />
  )  
}

Anyway, let me know what you think. I can let you in my private repos in Gitlab (I will end up open-sourcing all of this at some point, of course).

[DaniGuardiola]

Don't know about becoming a core maintainer tho. I would sure love to be involved in evolving the idea and could also spend a few hours a week with some bugs but I can't promise any consistency. Count me in as backup maintainer tho. I'll help. I know the code pretty well at this point. At least the <Editor /> one.

I'd be glad to lead the "next" effort as long as it is in this direction I propose and be core maintainer until it becomes stable and everything is upgraded.

[DaniGuardiola]

Oh, one last thing, I intend to turn all of the code into Typescript once I'm over the prototyping phase.

[juliankrispel]

@DaniGuardiola thanks for expressing interest. See Niks comment above for becoming a maintainer, these prs can be smaller than rewriting the Editor btw, I'd recommend smaller PRs because they're easier to review and QA. Either way I'll do my best to help you succeed, looking forward to your contributions!

[DaniGuardiola]

@juliankrispel thanks for your answer.

First things first, full disclosure: I'm working on this mainly for fun. This doesn't mean, however, that me having fun and this project being maintained are incompatible.

And regarding @nikgraf's comment:

1. Although right now my priority is getting my editor to work, I do love the idea of draft-js plugins and I'm definitely for the bigger picture too. I will gladly put my personal needs in the background. In fact, my editor is almost finished at this point, so I won't have any personal needs regarding this project for much longer.
2. I don't know how to prove I'm trustworthy, but I guess as long as I'm not the only approver it should be fine?

In conclusion, I'm very interested in helping out, but here's my two considerations:

• I would like to focus especially on evolving the Editor component and plugin design patterns, and creating / transforming plugins in relation to this, etc. I can still help with other stuff though.
• I can't really guarantee any consistency. My life is kinda unpredictable right now for personal reasons. On the other hand, all of my summer plans are no more (thanks covid), so I will have more time than usual for side-projects such as this one.

[DaniGuardiola]

Hi, apologies for the elevated volume of messages but I'm moving very fast with my project and I just decided I'm switching to slate because it better fills my project's needs. Thought it was worth communicating it.

That said, while I won't be using Draft.js anymore, I am still interested in helping with the modernization of the Editor component (the initial work is about half done already!), and implementing new plugins / transform existing ones in relation to the modernized Editor.

Sorry if that doesn't exactly fit your need for "project-wide" maintainers, I just hope I can help with this specific part of the project, which is the one I'm interested in.

[NaviMarella]

Hi, I have some experience using draft js and using plugins in my current project. Basically we have re-written few plugins according to our needs and used basic plugin editor.

For maintainers, I can be part of building some plugins and improving draft js for larger community.

[NaviMarella]

Just curious, Which approach are we going to follow for future ??

1. Existing draft plugin system in this repo ??
2. convert all plugins to context approach as in this repo(https://github.com/draft-js-plugins/next)

@juliankrispel What are different problems you faced with draft-js-plugins/next context approach.

[DaniGuardiola]

As I don't see any answer yet (I know you're probably busy people 😄), here's my plan of action: I'm gonna review the next repo approach and see if I can come up with a clean design merging both your ideas and mine, and I'll create a repo with the implementation and some plugin examples. Then, you can do whatever you want with it. I'd like it to be part of this project, if not I guess it'll be its own fork. I'll try to keep things as compatible as possible to avoid fragmentation.

[juliankrispel]

Hello there. Just to clarify. To become a maintainer, please follow the steps as outlined by Nik here, if you are serious about becoming a maintainer and have opened prs which have not received a review or feedback, feel free to ping me directly, in this thread or elsewhere.

The next repository has been archived since it is not the main repository for this project. It is our intention first and foremost to find maintainers for the current version of draft js plugins (this repository). I hope that clarifies things a little. If you have more questions please lmk I'm happy to follow up

[sibelius]

I can help to review current pull requests and issues

I want to fix at least the strict mode react warnings

[sibelius]

send me pull requests that you wanna me to review and I will review and merge if everything is all right

[nikgraf]

I just gave @sibelius ownership of this Github organisations and made him a collaborator to the npm packages? I trust him to maintain this project and make it even far better.

If you have any questions or concerns feel free to reach out to me directly.

[juliankrispel]

👍

…

On Tue, Sep 1, 2020 at 9:48 PM Nik Graf ***@***.***> wrote: I just gave @sibelius <https://github.com/sibelius> ownership of this Github organisations and made him a collaborator to the npm packages? I trust him to maintain this project and make it even far better. If you have any questions or concerns feel free to reach out to me directly. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1407 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJCCWUFCPJ4V5VQOORTGDDSDVM2HANCNFSM4M2Y3DHQ> .

[sibelius]

@DaniGuardiola do you wanna contribute to this repo?

I think this #1407 (comment) is a good direction

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.