/meteor-react-notes-app

A meteor app for storing notes, UI primarily rendered in React and styled from scratch

Primary LanguageJavaScript

This is a pretty rough Meteor, React and LESS driven notes app. Core functionality operates fine although this is the first time I've used React Router 4 and I'm so used to Redux that I'm sure there's some weirdness elsewhere.

Styling is done using LESS and is somewhat responsive to mobile (designed to remain operable down to 320pxw, which I believe is iPhone 5/SE's pixel width), functionality and basic layout issues were the focus. Color choices are 100% arbitrary (hence why it looks like a myspace profile at points), interaction styling is highly limited. I've tried to flag features not currently implemented with a serif font class. All content is designed to remain onscreen using vh and calc values.

Drafts doesnt work, the view currently fetches notes in reverse order as a placeholder

Motives

  • To refamiliarise myself with Meteor
  • A React project without Redux
  • No CSS framework

To be added

  • Proper CSS efforts, thinking CSS Grid
  • Responsive design
  • Confirmation modals
  • Drafts (all the layout stuff is roughly in place, some issues to be figured out as to how to store drafts of edits to existing notes, I assume another collection with foreign keys for saved edits to existing notes)
  • Autosaving (simple combo of actions with timers triggered by the change handlers on forms)
  • Validation

Issues

  • Meteor's subscribe system results in direct renders of links to individual notes failing
  • Drafts will likely need a separate collection or some convoluted cross referencing
  • ESLint is a bit messily implemented at the moment

To run

meteor

Objectives

To build an app for taking notes

A. Key features

  1. Add a note (consisting of a title and/or)
  2. List of notes
  3. View a note B. UX features
  4. No CSS framework
  5. Responsive
  6. Intuitive
  7. Notes appear in modal, closable C. Technical
  8. Persistent data
  9. Autosaving
  10. Testing

B UX choices

I didn't use a CSS framework but used the LESS preprocessor to simplify the styling process. as mentioned above, VH and calc are used heavily to ensure the full screen space is used. The existing UI is far more focused on raw functionality than looking nice, I've tried to use variables and rem values in the CSS as much as possible so it can be easily edited.

The modal request was pretty much ignored as I felt on desktop it made more sense to make use of the extra space so one can navigate through the list and read a note at once, and modals are generally a bit gross on smaller phones. On mobile (using iPhone 5 as the minimum screen specs), the pages that aren't explicitly for displaying the lists have been given crude media queries to only display the other content, treating them like a pop out menu would likely be preferable.

The list is sorted by the date last edited, but date created is also stored so multiple sorting options could be a future feature as well as a basic search operation using filter.

The drafts section, which is currently not operating, is due to the proposed autosaving feature. As a user, while I would appreciate autosaving, I would not want my existing note to be constantly overwritten unless that was very apparent. The best solution seemed to be a drafts system not unlike on most email services. I haven't put huge thought into this, it mostly allowed a chance to reuse a component (CellList.js).

The view and edit pages were designed to have closely similar layouts (ie everything fitting within the same space). The color choices have been done to make it pretty apparent when it's an editable interface.

C Technical

Data is persistent on a MongoDB database set up by meteor. The implementation is a pretty simple expansion on their react tutorial's server, contains no encryption or authentication but a user can only view their own notes here.

Autosaving is currently not implemented but would be pretty easy to do so. The inclusion of this spec is what made me decide a drafts option would be needed. In terms of schema, each note would need a flag for when there is a connected draft; both drafts and notes would probably need foreign keys to one another (assume a maximum of one draft per note). Drafts would also need an option to save as a new note as opposed to overwriting the existing one.

There's no testing in this implementation. Would appreciate some recommendations on which parts could best do with testing.