Hi, Thanks for your great open-source project 😍. I have a challenge with this editor, maybe you can help me.

I want to set and save the block's unique id in DB for some features like comments or the block's history. Do you have any idea about that? Notice that text or structure changes shouldn't change id.

Thanks.

Typing /heading shows two variants: Heading 1 and Heading 2.

However, typing /h1 to quickly access Heading 1 doesn't work. The same is for /h2.

Additionally, if I insert spaces, just like /heading 1, the search ignores the space, tries to look for heading1, and says that nothing was found. And backspacing three times after that leaves /headi in the search box instead of /headin.

To reproduce:

1. Convert block to any other type of content block using slash syntax
2. Caret will be put at the end of text even if slash was somewhere in the middle

Probably the reason for this: Lotion.vue::setBlockType() calls moveToEnd() even if transformation was invoked with slash syntax. There is a call before that in Block.vue::clearSearch() to set carret at right position.

Currently, converting between text type blocks (text <-> quote / text->text / quote->quote) results in loss of bold and italic tags

• Modified Lotion.vue::setBlockType to use html content instead of text content when target block is text/quote (solves conversion with no search)
• Modified Block.vue::clearSearch to take into account html content - now if type of block before conversion is text/quote, it will store the html content in addition to the text content, and if the type of block after conversion is text/quote, it will use the stored html content. (solves conversion via search)

Tags are still lost when converting to heading types, could potentially find a workaround with the current implementation but @holazz's refactor in #39 will potentially make it much easier (I think we would be able to use the same logic as text blocks)

Proposed solutions for #27 and #29

For #27, Block.vue::clearSearch previously wouldn't trigger on a single slash since the slash was not added to searchTerm. Also changed <= 1 to <1 to support single character search terms (e.g. /h)

For #29 please see issue

I was playing around with the demo at https://lotion.dashibase.com/ and noticed that if I delete all the blocks (I started at the bottom and moved upwards, leaving just the main heading remaining), I get into a state where I can't seem to add any new blocks. At this point, I don't see a tooltip to add a new block and the '/' shortcut doesn't popup the menu to convert a block to a particular type.

Proposed solution for #10

Using handle property for draggable

Associating handle with BlockMenu component ensures that blocks can be dragged only when the user is dragging the BlockMenu icon, instead of anywhere on the div. Mirrors actual notion behaviour. Example

Removing default behaviour for drop event

Issue where dropping a block inside itself would result in unwanted behaviour, seems to be caused by the HTML drop event on the editor. Preventing the default drop event inside the editor seems to fix the issue.

Side note: The following solution seems more clear, but it throws a typescript error for some reason. Current code does the same (Reference)

    editorProps: { 
      handleDOMEvents : {
        drop: (view, event) => {event.preventDefault()}
      }
    }

Comparisons:

Before:

https://user-images.githubusercontent.com/23100055/182024052-c7a31e5d-520f-46b0-afe6-2b443aea1d2e.mov

After:

https://user-images.githubusercontent.com/23100055/182024060-cc95d4ee-6d26-4c5b-88ec-f0ef8cc24851.mov

There is no need to send event to clear search term if there is none.

This also fixes bug that removed last character when transforming from Text into Heading. Should I also create issue for this?

This pull request:

• Makes search more convenient by using fuzzy search instead of String#startsWith
• Fixes a bug of search term not being set back to an empty string when user presses Esc or clicks outside the block menu
• Fixes spaces being ignored when a user inputs a search query. Notion doesn't ignore spaces (you can type /heading 1 and it will work)

Description

This PR addresses #12

• default blocks to have id
• new blocks to have id
• In the HTML DOM, blocks also have the id of block-${block.id}

Screenshots

Setup + basic tests using playwright

Currently implements the following (E2E) tests: | Use Case / Feature | Expected Behaviour | |-------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Basic typing / editing | Text should update as user types
Text should be formatted appropriately when user inputs bold/italics | | Converting between types | Blocks should be converted appropriately when user selects a type from the menu
Blocks should be converted appropriately when user initiates conversion by searching/typing
Caret position should be maintained after conversion if initiated from search | | Creating new lines / Breaking lines | Pressing 'Enter' at the end of a block should create a new line
Pressing 'Enter' in the middle of a block should create a new line containing the text after the caret position | | Merging two lines | Pressing 'Backspace' at the beginning of a text block should merge the current block's content with the previous block
Pressing 'Backspace' at the beginning of a non-text block should convert the current block to a text block |

I also included an example using playwright's component testing (c9a30f1fbde21fe0b65abc9c014f1a486ba78891 and 89329ed9fb307f0edd9c6209e9a18c3824f9aeea), which will be very useful since it allows us to mount components with custom props. (eg if we want to test custom inputs like bold/italic bold/headings etc we can mount the component with these inputs instead of having to create them in an end to end test)

One 'downside' of playwright compared to cypress is that we can't (to my knowledge) access instance methods (for example directly calling Lotion.vue::getCaretPos()), but we can still test the correctness of the methods outcome e.g. by initiating a change in block type via the menu.

Also, I'm not sure regarding CI (I'm not familiar with AWS), currently npx playwright test is configured to start the local server with npm run dev and test on that url - might need some changes for CI.

As more features are being added, it would be great if we can set up automated tests to verify the correctness of any changes and ensure new changes don't break current features.

This is a very rough draft using cypress which includes some basic tests for Lotion::split, Lotion::merge, Block::getCaretPos and Block::getCaretPosWithoutTags.

Would greatly appreciate any input/suggestions on the approach/organization etc or if anyone would like to suggest another testing library. Wanted to check on this approach before I proceed to write more tests covering the existing features.

Currently, converting between text type blocks (text <-> quote / text->text / quote->quote) results in loss of bold and italic tags

• Modified Lotion.vue::setBlockType to use html content instead of text content when target block is text/quote (solves conversion with no search)
• Modified Block.vue::clearSearch to take into account html content - now if type of block before conversion is text/quote, it will store the html content in addition to the text content, and if the type of block after conversion is text/quote, it will use the stored html content. (solves conversion via search)

Tags are still lost when converting to heading types, could potentially find a workaround with the current implementation but @holazz's refactor in #39 will potentially make it much easier (I think we would be able to use the same logic as text blocks)

redo of #42 with correct commit history

Currently, working with text that is both bold and italic causes a few functions to break

• Arrow key navigation doesn't work if italic bold text is at front/back of block
• Merge doesn't work if italic bold text is at the front of the block that is being merged
• Split doesn't work if initiated from within the italic bold text
• Conversion via search doesn't delete search term if initiated from within italic bold text

Issues are mainly due to the tags being nested, since most functions currently only work for one layer of nested tags

Fix would require a decent amount of refactoring to support nested tags

Description

In Notion, when you click on the "+" button next to the block, you will see a context menu to choose the custom block that you want to add to your document, so there isn't a behavior of repeatedly clicking on the "+" button.

However, in Lotion, right now, when we click on the "+" button repeatedly, the caret is immediately moved to the new block. This results the user to leave where they are previously. While this logic does seem to follow how Notion implements it, it is not ideal for users that just want to add multiple placeholder blocks.

Screenshots

Seeing how Dashibase is getting many issue report & PRs, it will be great to include som templates so there's a standard for new contributors to follow when creating an issue for bugs/ feature requests, and when they create PRs for them.

Examples of GitHub templates can be found here and here