Perhaps this can be done by disabling the editor and changing the placeholder to say that the editor is out of service for now.

It's evident that LocalStorageService can be further improved and refactored. Tests should be written as well for it.

When should this part of the pipeline be dropped? For how many versions do we want to have support for? Perhaps only supporting version 16 of Node is fine?

I assume this is due to some type error between Cypress and Jest, should be easy to address.

Further information on OpenCovenant/loanwords#7 (comment)

After writing some text in the editor that generate a marking, clicking on the toggle to upload a document, and then going back to the editor, you will see the placeholder along with the written text.

When writing on the text box and after u select all and delete the text the "karaktere" number stays the same only "fjale" and "shenjime" goes to 0

Self-explanatory title.

When mousing over or clicking on a marking in the editor, perhaps we should highlight the corresponding marking from the right (or below in mobile)?

Consider storing the written text in the editor in a query parameter in the editor. What would be the benefit of this, sharing the link with the written text? In that case, consider creating short links with such contained written text.

When a typo is currently found, the styles that are applied to it feel quite sudden, perhaps they can be done slightly smoother (maybe through a quick transition or so).

Please note that this issue is only about making the feel of the styling a bit more natural/smoother, and no logical change should be made to the markings for now.

The "x" icon seems to be quite close to the right border on mobile view, it evidently needs some refining.

Consider how would a Dark Mode work in our case?

The generated numbers of karaktere, fjalë, shenjime are different than those of many other applications. Check the RegEx and discuss on what the generated numbers should be.

As more functionality is being added, the more likely it is for the user to miss certain features that might help them. In this regard, consider adding some sort of a walkthrough that consists of a series of modals that describe certain aspects of the page in finer detail. Let's have this be at the list of items that is shown when we access our offcanvas component currently located on the top left part of the page (and not have it be shown right when the page loads as that might be annoying and/or intrusive to the user, but rather something that they can access to learn more from).

After writing some text in the editor that generate a marking and clicking on the toggle to upload a document, the user will see that the text markings will also include HTML.

The classes/components currently do not reflect their purpose. They should follow the single-responsibility-pattern similar to services

For now start with the HomeComponent. The major logic there is related to the Editor. The HomeComponent as the name suggests should just host the "home page".

Looking at the home.component.html it should end up looking as something like this or better:

<header></header>
<editor></editor>
<footer></footer>

with the relevant .ts class changes made accordingly. As a rule of thumb one should not see core editor logic on the home.component.ts.

This makes it easier to comfortably allow for even future structural changes, should new structural change decisions arise.

Steps proposed:

1. Start with the HomeComponent and extract all editor logic into an editor.component.ts , editor.component.html etc. and continue with other ones later on (recursively) until no major inconsistencies exist.
2. Create a PR label on GitHub like: "Angular Component Restructuring" or "Component Restructuring" or something better to track this and future changes like this
3. All PRs regarding restructuring and labeled as such should not touch or change any other logic or function or property names etc,.

The PRs aiming to fix this and other issues should follow the official guideline as a common accepted standard: Angular Styleguide
4. Add this guideline to the README file, or where applicable, as a note to future developers, to maintain long term code quality.

Currently deleting the text requires selecting it all and deleting it, or even reloading the page, among other techniques that don't feel organic. Adding an "X" in the top-right inside the editor that takes upon this functionality seems like a quick straightforward solution. Feel free to create a PR out of this.

uploading files doesn't find any error where there are clear intentional errors but instead shows this one:

As a novice contributor found it hard to extrapolate the purpose of functions. When making minor contributions to a small part of a small component, one shouldn't have to extrapolate the meaning of all other functions from reading the code only. This is easily alleviated by adding JSDoc based comments to the function, classes, properties etc,. The comment alone gives insight of what the method (or class , etc) does and inputs and outputs it produces. That gives enough knowledge to just know that that function execution or the specific class is not related to the issue being solved.
Also it avoids cases where one developer owns all the knowledge of previous code decisions which influence future changes, as this knowledge is put in the comments and shared instead.

As a line of work I'd suggest the following:

1. Agree to follow a common comment guideline: the Google Javascript Style guide for comments and other guidelines
2. Add this guideline in the README file or where applicable as a notice to future contributors as a rule to maintain long term code style quality
3. Add PR label: JSDOC or Code Comments or some other name, to note all future PRs dealing with adding JSDoc to the codebase. Related PRs should only change/add comments and not touch any logic.

Add a simple setup first. Extend later

As hinted in #86 there's CSS code that is redundant (stale code from recent refactoring). A PR should be made to drop such styling.

when pressing enter really fast it causes the cursor to lag and makes the cursor go to the line above where it is supposed to be the video explains it better
screen-capture (2).webm

When pressing "ENTER" in the text box it adds 4 karaktere even tho its empty

The main point of this issue is properly elaborated in PR #1 , so I'll just display that extract.
It is unclear from the README file what the architecture of the project is. Maybe one good idea would be to include a simple UML top-level diagram depicting the interaction of this front-end repository with its back-end counterpart.
I'd say to create a PR out of this with the relevant changes, without spending too much time on it for now as certain abstractions might soon evolve.

Manually writing the path to the page of some marking details, e.g. /te-dhe-tek seems to work locally but not in production.

Similar to the screenshot above, research/investigate how this can be applied to this repo, as a good mechanism to prevent issues such as merge conflicts and other ones.
Come up with a solution to have something like this, or note why we can't have it.

On live server penda.info when you paste something and select it all,delete it, and paste it again it freezes the browser and the computer sometimes it just freezes by itself even when you are not using it

Given that we've now added paragraphs to the editor, the default HTML of the editor is <p><br></p> which breaks the placeholder text shown in it. Previously it was empty and the placeholder would show, it can also be shown be clicking in the editor and pressing Backspace.

Consider moving the current CSS from

#editor:empty:not(:focus):before, #editor:empty:focus:before {
    content: attr(data-placeholder);
    color: #C9C9C9;
}

to JavaScript that renders this if the innerHTML of the editor is <p><br></p>, or I assume some similar solution.

The corrent behavior should be to show the placeholder only if the editor's inner HTML is <p><br></p>.

Functionality such as the one described in HomeComponent.handleRequestForStoringWrittenTexts could perhaps be simplified by using debounce?

As of now, when choosing a suggestion, it is not communicated properly to the user that the suggestion has been applied and more requests for going through the text have been made, which makes the user uncertain on whether they should or shouldn't immediately choose another suggestion.

Explore the two following potential solutions.

• Adding a spinner on top of the grayed out list of markings will alleviate this issue and the user will then know that they have to wait for a short period of time until they can apply other suggestions.
• Make no request to the backend immediately after applying the suggestion, but wait for a given amount of time that is reset after every suggestion.

It is quite likely that we will end up on a solution that includes both of these.

In some later iPhones, when clicking the copy button to the clipboard down below the editor, it incorrectly focuses in the editor.

One of the cypress tests were one that clicks on expand arrow but when you run it on npx cypress open everything was alright and it passed the test.
When run on npx cypress run it failed all the time on electron
But when you add npx cypress run --browser chrome 1/10 test cases it failed In chrome
Below I'm showing the test code :

    it('will click on the expand arrow and click on all suggestions and close it again', () => {

        cy.get("#editor > p > .typo").should("not.exist");
        cy.get("#editor").type("fshji ");
        cy.get('h3.bi-arrow-right-square').click();
        cy.get('button.suggestion').contains("afshi").click();
        cy.get("#editor").contains("afshi").should("exist");
        cy.get("#editor").clear();

        cy.get("#editor > p > .typo").should("not.exist");
        cy.get("#editor").type("fshji ");
        cy.get('h3.bi-arrow-right-square').click();
        cy.get('button.suggestion').contains("shaji").click();
        cy.get("#editor").contains("shaji").should("exist");
        cy.get('h3.bi-arrow-left-square').click();
        cy.get("#editor").clear();
    }); 

The error that cypress throws for running this is :
AssertionError: Timed out retrying after 4000ms: Expected to find element: 'h3.bi-arrow-left-square', but never found it."

Attached is an image of a marking (from an experimental branch) of a very long sentence. This clutters the markings area and does not provide much useful information.

I'd prefer to have it be shown in one line, with the text in the middle replaced with ellipses, as in the likes of "Kjo është një ... shumë e gjatë.", with the actual number of words shown depending on the display (this is optional to an extent).

Referring to text-overflow might be fruitful.

Let's make a list here with additional Cypress tests we want to add.

• Click on the information button of some markings that lead to pages with further details on the markings.
• Clicking on the upload-document tab and then back on the writing-tab, the text should be kept.
• Opening and closing the offcanvas works as expected.
• Copying test by clicking the copy button adds the selected text in the clipboard.
• Written text is added to the history of texts as when expected.
• karaktere, fjalë, shenjime change as expected when text is written in the editor.
• The placeholder works as expected.
• The default markings that are shown when the page is loaded and no text is added are shown as expected.
• Top-left home penda button
• Automatically focusing on the editor for some screens (e.g. of width higher than 800px)
• The position of the cursor in the editor on various scenarios.
• The order of the markings shown on the right-hand (below for mobile) side of the page.

The UI seems a bit too reliant on backend data. The UI seems to still refresh even if there's no proper data available. That's why it is necessary to validate backend data before initiating a UI-Refresh (DOM re-rendering), which not only slows down but also produces plenty of un-anticipated 'undefined' console errors.

Suggested idea depicted below:

• Validation of data can be done in FE
• Invalid Data = undefined, empty string, dead server, pending request,.etc
• Give user feedback if server is "currently unavailable"
  

Straightforward list of Cypress tests related to the highlighting of a marking.

• Typing in the editor removes the focus.
• Clicking on the remove-highlighted-marking actually removes the highlighted marking.
• Removing the highlighted marking by selecting all the text and deleting it, actually removes the highlighted marking.
• The selected marking is sticky.

Let's have a loading spinner that shows up when we are making a call for generating the markings of a given text.

There's already some commented out code indicating this wanted behavior, perhaps use that as a starting point.

If you click the button "Dokument", and then click the button "Shkrim" , the editor is enabled again.