Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Content editor extension type #10387

Open
12 tasks
Tracked by #7930
kulmann opened this issue Jan 22, 2024 · 0 comments
Open
12 tasks
Tracked by #7930

Content editor extension type #10387

kulmann opened this issue Jan 22, 2024 · 0 comments

Comments

@kulmann
Copy link
Contributor

kulmann commented Jan 22, 2024

Description

User Stories

  • As an extension developer, I want to add support for content editing/rendering for specific mimetypes to the texteditor app so that I don't need to rewrite all the texteditor app business logic in my own app (permission based decision for read/write view modes, autosave, etc).

Value

  • separation of concerns (business logic for text based content editing vs. support for different mimetypes) / reduce code duplication
  • make content editing / rendering available as a component for inline contexts outside of the texteditor app

Acceptance Criteria

  • define a contentEditor extension type (including whether it supports rendering, editing or both)
  • refactor texteditor app so that both editors (unstyled plain via textarea and markdown via toastui) are not hardcoded in the texteditor business logic anymore but a) registered as extensions and b) then used internally content editing/rendering)
  • look into https://www.npmjs.com/package/monaco-editor for syntax highlighted editing of .css, .yaml, etc, but build that as a separate extension, not as part of the texteditor (the texteditor will then be able to use the extension)
  • cherry on top: use the extensions for e.g. editing the space description (= markdown) with an inline editing component

Definition of ready

  • Everybody needs to understand the value written in the user story
  • Acceptance criteria have to be defined
  • All dependencies of the user story need to be identified
  • Feature should be seen from an end user perspective
  • Story has to be estimated
  • Story points need to be less than 20

Definition of done

  • Functional requirements
    • Functionality described in the user story works
    • Acceptance criteria are fulfilled
  • Quality
    • Code review happened
    • CI is green (that includes new and existing automated tests)
    • Critical code received unit tests by the developer
  • Non-functional requirements
    • No sonar cloud issues
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant