rtjoa / modular-documents Goto Github PK

For document editing, add a history stack for when the array of module data's changes, then use this to add undo, and an unsaved changes on closing the page when there are outstanding changes.

Note: #29 should be addressed first.

• Create state.unsaved in Document module, and set to false on doc load and save
• In setData, moveModuleUp, moveModuleDown, deleteModule, and addModule, set state.unsaved to true
• Give navigation warning if state.unsaved is true

Let user choose between three levels of visibility for documents they own (currently, this is always 0)

• 0: only owner can see
• 1: anyone with link can see
• 2: searchable from explore page

Allow modules to be searched by whether the query is a substring of the title, rather than just if the title starts with the query.

Maybe also have modules store "searchText" tailored to their type, and look for matches in that.

• Choose DB service
• Design API endpoints & DB structure

Each module should have a integer version number associated with it.

When we change how the data for a module is represented, we increment its version number, and add a function to upgrade the version.

For example, say TextModule starts at version 1, and its data looks like {text: "Lorem ipsum"}:

// TextModule.js
TextModule.version = 1;

When we add a 'font_family' property to text modules, we increment the version to 2 and define a function to dictate how we upgrade from version 1 to 2:

// TextModule.js
TextModule.version = 2;

// TextModuleUpgrader.js
const UPGRADE_FUNCTIONS = {
  2: (data) => ({...data, 'font_family': 'Arial'});
}

If, in another update, we decide to represent text data as HTML, then we could do the following:

// TextModule.js
TextModule.version = 3;

// TextModuleUpgrader.js
const UPGRADE_FUNCTIONS = {
  2: (data) => ({...data, 'font_family': 'Arial'});
  3: (data) => `<p style="font-family:${data['font_family']}">${data['text'}</p>`;
}

Then, if need to render/edit a Text Module from version 1, we set its data to UPGRADE_FUNCTIONS[3](UPGRADE_FUNCTIONS[2](data)).

Let modules call functions to get/set server data associated with that module specifically. This would allow poll modules, and for modules to persist data for individual users.

Users should be able to like others documents so we have a way to sort the explore page by quality.

It would also be cool to be able to sort by "Top" (most likes) and "Hot" (formula like this).

Some other considerations about document discovery:

• Perhaps we also have different types of likes, such as useful/interesting/funny
• With just basic liking, we could implement recommendations, e.g. "Documents you might be interested in"
• Document tagging, by the creators (e.g. most articles) and/or the consumers (e.g. Steam games)

• Welcome
• Edit document
• View document
• My documents
• Explore

https://reactjs.org/docs/testing.html

At least Markdown should apply almost wherever the modules can contain text. Combining it with code block and LaTeX parsing (removing the need for individual modules for those) would be nice too.

We should only store each module's data, not its tempData or editing properties.

Document thumbnails could preview document contents, like in Google Drive: