jrobind / dev-jot Goto Github PK

The modal or dialog should close after clicking on the black background

Currently the pre-auth sign in button isn't actually a button element it is a div.

For accessibility reasons, we should either convert this to a button element or keep this as a div but make sure this is accessible for screen readers. (tip, Google search for aria attributes & roles). Either way, make sure the styling remains consistent.

Instead of the text simply being cut off, it would be nice to be able to scroll through the text preview. The whole text is being loaded anyway, isn't it? If it isn't, then I guess we save some bytes (potentially kilobytes at best) of data by only having the preview show a max limit, but if it is, then a scrollable implementation would be easier than having to manually click "view lesson." (Imagine if you had 30+ lessons)

Currently the quill and firebase initialisation and configurations are located within a script in the HTML.

It would be better to have all of the JS grouped together, better still, we could start to modularise the JS using JS modules and have this config and initialisation moved into its own file.

Currently the lesson count alignment is a little off relative to the "Lessons" text:

It would be nice to include an 'add link' option in the toolbar editor.

Currently you can scroll the homepage content which I think looks a bit odd.

For now we should prevent scrolling and have content fill 100% viewport height.

Running a lighthouse audit returns some accessibility issues regarding heading element order.

This will cause navigation issues for screen reader users. This article explains in more detail why this is a problem.

We should fix the heading order to ensure a smooth navigation experience for screen readers.

Currently any JavaScript errors that are caught are being printed to the console with console.log or console.error.

I think it will be more useful for the user to receive some feedback if a request or action fails.

For instance, if a user attempts to remove/delete a lesson and this request fails the lesson card remains on the screen and the process fails silently which is confusing for the user.

I think it would be cool to have the total number of lessons visible to the user.

Maybe we could place the total near the Lessons heading:

Open for suggestions on what this count/total would look like!

There are no hover effects for buttons across the app.

Other than cursor: pointer, I think it would be nice to have a cool global hover effect. You can make it as fancy as you like, just make sure the hover effect is consistent across all buttons.

We could do with a little more space below the lesson close button and the lesson content container:

When scrolling a lesson, the close button does not stick to the top of the modal. As a result, you need to scroll back to the top to close the modal. This will be annoying for lessons with lots of content. Although you can close the modal using the Esc key, this won't be obvious for most users.

In the Current State paragraph of the readme file, in the 4th line, there is a typo in the active link instead of live verson it must be " live version"

I think it would be cool to use styled components for the React version of the project.

This issue can cover installation and basic configuration.

The update lesson button text wraps throwing out the button styling.

If we have any budding designers it would be cool if we could come up with a rough design mockup for the lesson tag filter feature outlined in #62.

The renderLessons() function is quite large. It feels like it's doing to much at the moment i.e. it's fetching, it's creating and it's also rendering.

The logic to create DOM elements seems pretty repetitive too - maybe we can create some sort of utility function to handle this more elegantly?

Currently all of the JavaScript code lives in one file.

It would be nice to move the code into separate modules which will encourage reusability and improve maintainability. Modules should be small pieces of code with independent functionalities which means that they should be easier to test too.

The code could be separated out depending on it's function. If you're unfamiliar with JavaScript modules then I'd recommend reading the docs.

Because the site is missing a viewport meta tag, mobile devices actually render a scaled down desktop width page making content difficult to read and interact with. We should include one in the page head to fix this whilst making sure this passes a lighthouse audit too:

For more information you can check the documentation.

It would be nice to improve development workflow and automate some tasks such as optimising assets like CSS, JavaScript, and images with gulp.

Gulp is considered a build tool along with the likes of grunt and broccoli. Gulp config tends to be a little shorter and easier to write (imho) so it might be the best build tool for beginners. Open for discussion of course!

As a starting point, whoever takes on this task could focus on getting gulp set up. We could raise separate issues to tackle asset compression/optimisation etc.

Note: Reloading the page inbetween editing and creating a new lesson will cause the issue not to happen.

Links to #62

As part of the lesson tag filter feature, a user should be able to add tags to a lesson. The markup for this will need to be added to the create/new lesson form.

Some thoughts:

• This could be achieved by adding a drop-down list with a predefined list of options
• Should the user be able to define their own custom lesson tags?

As always this is open for discussion 😄

This issue covers updating the document head, including meta tags, links and title in the React app to match the attributes of the main dev-jot app as seen here: https://github.com/jrobind/dev-jot/blob/master/app-main/public/index.html

[Happy to take this on to get the ball rolling but for future issues I'll give space to someone else 😉 ]

I'd recommend using jest, but open to discussions on this.

This issue could cover just the testing setup and configuration.

In terms of actually writing some meaningful tests for our code, this will probably require a bit of extra work and refactoring. We might need to move our JS logic into a class which will make testing methods/functionality much easier.

If I edit a particular lesson and then delete it, if I then try to add a new lesson it fails silently and the lesson isn't added:

If you're struggling to debug this please follow this code reading process.

Currently when you view a lesson

The only way to exit/close the modal is to click the close button. The modal should be closable with the Esc key which will improve modal accessibility for keyboard users.

Lesson cards have cursor: pointer applied which gives the user the impression that the cards should be clickable but they are not.

We should remove the cursor styling.

Although the app works on mobile, currently it's only set up for desktop users. We should update the app to work on smaller viewports. Maybe the editor and lesson grid should stack into a single column? This issue is a little vague so there is scope to do lots with this.

If anyone wants to pick this up maybe it would be best to have a discussion about next steps here.

This refactor will make the asynchronous code a little easier to read. The MDN docs are a good place to start if you need a refresh.

The lesson modal looks a little dull.

We could spice up the design whilst keeping colour schemes consistent with the rest of the site. If you're having trouble finding stylistic inspiration maybe take a look at https://dribbble.com/tags/modal

Currently when you edit a lesson the clear button appears:

It would be nice if there was the option to also clear content when a user is creating/adding a new lesson.

Currently this is the default Firebase 404 markup.

Let's update this so the page is more consistent with the rest of the site design.

Currently if you tab into the editor you cannot tab out of it. This causes a keyboard trap which is bad accessibility.

Essentially, we need to prevent WCAG 2.1.2 No Keyboard Trap.

A possible solution is to allow the escape key to exit the editor.

After some discussion in the Discord channel we might want to approach this by:

• adding a checkbox that allows you to enable/disable tab inside the quill editor. Once active you'll need to press esc (or click) to deactivate tab allowed mode
• alongside a checkbox, we might also need an onscreen message informing the user that hitting escape will allow them to tab to the next element.

When running locally i get this message:
auth/unauthorized-domain This domain (127.0.0.1) is not authorized to run this operation. Add it to the OAuth redirect domains list in the Firebase console -> Auth section -> Sign in method tab.

Cannot Sign in with Google.

I think prettier would be a good fit. It would save beginners having to worry excessively about linting. With prettier all the formatting is handled for you.

Open to discussion/suggestions on this!

Let's add a favicon!

Links to #62

As part of the lesson tag filter feature, a user should be able to filter lessons by tag(s). It might make sense to create 2 tickets, one to handle the UI and the other to handle the filtering logic.

Things to consider:

• Where will the filtering controls live?
• Should the user be able to filter by multiple tags?
• Should we display something to the user in the event there are no matching lessons for the selected filter?
• Should the user be able to reset the filter state/selection?

This is an epic issue. List of individual issues needed to achieve this epic are below:

• Add lesson tags logic #59
• Modify UI allowing user to add lesson tags (#60)
• Implement lesson tag filtering #61

When the lesson view modal appears there is no focus trap which is bad for assistive tech users. Currently, there is no way for a user to tab onto the close button and screen readers will also be unaware that a modal has appeared on screen.

I suggest we follow the W3 spec: https://www.w3.org/TR/wai-aria-practices-1.1/examples/dialog-modal/dialog

The application can't fetch the manifest icon. Probably the paths are not correct in the site.manifest file.

Summary:

• create a new Header React component
• handle any logic in the header - saving a new user to local storage and randomly assigning an avatar image
• include header styles as part of the component using styled components

(I have already done this and I'm linking the PR 🚀 )

Links to #62

As part of the lesson tag filter feature, a user should be able to filter lessons by tag(s). This issue should cover just the JS implementation of adding tags to lessons.

Hint: you can add the tag field/property somewhere within addLesson() and you can check to see if this works within renderLessons.

As the title says: creating new lesson and selection font size does apply to lesson overview but not to "view lesson" view.

As of this posting, only styling via the built in editor is available.

As this is a tool for developers, I think it would be useful to be able to format our text appropriately.

I don't know how to tag this post with appropriate labels, so my apologies if I am not following a convention for posting issues. I wanted to label this as an enhancement. Unsure of how the difficulty of implementation would be.

Currently, a user is prevented from creating a lesson that contains no text. Even though the validation logic is correct there isn't a message or visual cue to inform the user the lesson creation has failed.

Adding an .editorconfig file will help to maintain consistent coding styles for contributors working on the project across various editors and IDEs.

Here is an example config:

# stop .editorconfig files search on current file.
root = true

# Unix-style newlines with a newline ending every file
[*]
charset = utf-8
end_of_line = lf
insert_final_newline = true
indent_style = tab
indent_size = 2
trim_trailing_whitespace = true

Please see the docs for more information

• Add an editorconfig file so that code style is automatically applied
• Add an .nvmrc file so we're all on the same node version
• Fix the eslint setup so it's there for those that want to use it
• Add a lint command to npm to report on pretteir and eslint findings

As a PWA the site would have a really cool offline experience and also have the look and feel of a native app. We have the manifest already set up, and the site is served over https so the last thing is to ensure the app is installable. To do this, we need to have a registered service worker which will allow the app to work offline.

For information on PWAs please read through the MDN documentation
here is a specific article on service workers for PWAs