Submit a solution
The challenge is finished.

Challenge Overview

We are developing a new experience for our copilots and project managers: editing of challenge specs directly in the challenge details page. To check the initial proof-of-concept in action follow instructions in the challenge forum, to see just the editor demo check this page. Under the hood (we'll work from develop branch, commit 2e28959ace0ae16e4ba4dc9bbae11c4edbe6afdd), each editor field you see at that page is a separate DraftJS editor, and they all are inter-connected together and with the toolbar with the help of auxiliary Connector object. They don't rely on Redux, and use local states instead to achieve the best performance (DraftJS state is not a plain object, thus cannot be stored to Redux without conversions on each update, which has serious impact on the performance), and also to simplify their intergration into any page. Thus, each editor is responsible for managing its own state, and Connector is used to coordinate editor states with the toolbar state, and also to conveniently access all related editors in the page.

The goal of this challenge is to add additional functionality to the initial editors/toolbar setup (be sure to check the source code of DraftJS page - it is a first-hand example how the standard editing operations should be implemented in DraftJS):
  1. Make the editing operations in the toolbar disabled when none of the related editors are focused (i.e. such operations as bold, italic, i.e., that has to be applied to a specified editor; such operations like Save do not demand an editor to be focused, because they relate to the current content of all related editors, thus should not be disabled)
  2. Save button should be disabled/enabled when the editors content is not / is modified (i.e. at least one of the editors in the group has modified content).
  3. Add support for bullet/numbered lists, code blocks, note blocks, qoute blocks, headers. Design specs for the challenge details page are provided in the forum, and they are implemented in the current version of the challenge details page. We need to provide the way to create in the editor all types of blocks you can find there (no need for H1 title, as that one is for challenge titles only and should not be used inside the specs). These block types should be switchable by a dropdown selector in the toolbar, which should match the current styling of buttons in the toolbar (especially, when you use any font style, be sure to use the mixins demoed here, when you use buttons use the standard ones; we don't have that convenent way to deal with dropdowns yet, but we have this to be used for now). 
  4. Add support for URLs management in the text. It should work similar to URLs management in Google.Doc documents: when you select a text and press insert link, it opens a modal/dialog that accepts title and url. When you hover over a link in the text, it shows tooltip that shows the link, allows to click on it to follow it, and have the button to edit it. Note that we have generic Tooltip component in our codebase, we also have Modal component, which might be useful in this challenge, but probably in this point the Tooltip fits better.
  5. Add support for Image insertion. For now it will be fine to open a modal that accepts the image URL, shows it in the modal, allows to set the dimensions and insert it into the text. Once the image is in the text, hovering it should show an option to easily access the image insertion dialog to edit its properties. I don't have a clear idea, how should it look and work in the end, so use your best judgement to implement a simple, but functional way to insert the image by URL, keeping in mind that we'll want to add extra features in future (like copy/pasting the image from clipboard, uploading it from local drive, etc.). I am not sure whether it will be helpful here, but, just in case, we got this component which helps to create scalable HTML containers with the fixed sides ratio, probably it can be useful in this modal.
  6. Add options to highlight text / switch its color (similar to how it works in the traditional text editors).
  7. Markdown support. We want support Markdown format in the editor. The current idea is to have a switch in the toolbar: Markdown / WYSIWYG, which will switch between the regular and Markdown modes. In markdown mode each editor will split in two sections (vertically or horizontally - should be experimented, what is more convenient), one allowing the input, and another one showing the rendering results. Or, even, one showing and allowing to edit Markdown markup, while the other showing the rendered result and still allowing to edit it in WYSIWYG mode. Note that there are various readily available packages for Markdown support in DraftJS editor, along with examples of their use, so the goal is to choose the best tools and to add them into our setup - sure no need to write a custom converted between DraftJS state and markdown markup.
As always, if you get any doubts or ideas, do not hesitate to discuss them in the challenge forum. Our goal is to create the best possible editing experience (which will be used in other pages as well later), thus if you believe that something from this list can be done better, or we are missing something essential for the good experience, we wanna hear your opinion.

Final Submission Guidelines

Submit Git patch for Community App, and a brief demo video of the implemented functionality.


2018 Topcoder(R) Open

Review style

Final Review

Community Review Board


User Sign-Off

ID: 30061142