meteor / todos

The example app "Todos", written following the Meteor Guide

DEPRECATED

This repository is not used anymore as an example for Meteor projects.

Look for Meteor examples here

OLD README

This is a Todos example app built on the principles described in the Meteor Guide.

Versions

This version (the master) branch uses the Blaze rendering library, with code written in ES2015 JavaScript.

The react branch implements the same application using React

The coffeescript branch implements this (the Blaze) version of the app in CoffeeScript.

Note that attempts will be made to keep the branches up to date but this isn't guaranteed.

Running the app

meteor npm install
meteor

Scripts

To lint:

meteor npm run lint

todos's Issues

Figure out how to audit-argument-checks

Does out world support auditing Method validation?

Figure out what's up with the user profile

I don't know if we are denying it currently

Accounts-t9n is logging "UI is not defined"

Which is stopping our automatic tests from passing: https://circleci.com/gh/meteor/todos/5

Filter fields on publications

Make nicely styled email for resetting password

To demonstrate customizing email with HTML, using JS template strings.

Acceptance Tests / CI

• Adding new task
• Deleting task
• Editing task content
• Making list private (mobile and desktop)
• Deleting list (mobile and desktop)
• Changing list title (mobile and desktop)
• Registering
• Logging in
• Being redirected to a list when you go to the home page

Look at using https://chimp.readme.io to build these.

Unit tests

• Collection mutator tests
• Publication tests
• Method implementation tests
• Template rendering tests
  • Example with a mocked publication
• Template event handler tests (need to mock methods)

Update Application Structure to match guide

I think this includes:

• Renaming the packages to app- if that's what we are doing
• Deciding on collection file names + split (i.e. should the publications / factories / etc be in separate files?)

Integration Tests

• Test methods on both sides
• Test publications on both sides

Look at using: https://github.com/anticoders/gagarin to build these.

Determine whether we need to do something about browser-policy

Not sure about this one

Proper data loading -- stores + template level subs

Use tools for package management

Grab tools from: https://forums.meteor.com/t/tools-meteor-update-testing-for-packages-for-everything/11881/7

Ensure SSL

Perhaps by adding the force-ssl package?

Audit naming guidelines

https://github.com/meteor/guide/blob/master/outlines/structure.md#appendix-naming-guidelines

Update LaunchScreen code to be sensible

• Also mention in the guide
• (Also mention mobile config)

Make proper use of Less / CSS / PostCSS

Move assets into appropriate packages

audit argument checks and respondly mocha runner don't work together

Add OAuth login with Google

It's a shame not to demo this, and perhaps this means we should build out account merging?

There's a decision to be made on how deep we want to go into the accounts rabbit hole - perhaps we could leave this for later.

Componentize Blaze Templates

Follow all the patterns from the blaze article

Switch `lists/todos` to use publish-composite?

Something like:

Meteor.publishComposite('list/todos', function(listId) {
  check(listId, String);

  const userId = this.userId;
  return {
    find() {
      return Lists.find({_id: listId, {userId: {$or: [{$exists: false}, userId]}});
    },
    children: [
      {
         find(list) {
           return Todos.find({listId: list._id});
         }
      }
    ]
  };
});

This would mean:

a) We wouldn't need to have the userId denormalizer (we have a second denormalizer, so we still demonstrate the pattern)

b) We'd actually be using publish-composite, so we'd have an example to use

c) We'd also be showing how the authorization works

Add method tests

Should we use `throwStubExceptions` in methods so that we don't unnecessarily do optimistic stuff?

For instance, when trying to remove the last public list. I think yes.

Follow template naming guidelines

Make sure publications are secure and resilient to real-time permissions changes

For example, when a list becomes private you shouldn't be able to access its todo items anymore

Set up reset password flow

Make sure you can reset your password. This is a matter of figuring out how to get useraccounts to do it for us.

Improve pattern for list ownership to make it more explicit

Probably using a collection helper

Fix issue with onCreated data check

1. Need to resolve type of helpered-documents
2. Needs to be wrapped in an autorun

Render not found for unknown lists

e.g. http://localhost:3000/lists/xyz

Probably we need to wrap listShowPage in an {{#if}}. Or should it be done lower down the tree?

Should we apply i18n to the whole app?

add `list.todos` or `list.getTodos` and use it a helper

Investigate and run package scan

It's in the outline!

Use useraccounts packages for login/signup

Make sure email login is enforced at DDP level + tests

Right now, you could use Meteor.loginWithPassword to log in with a username from the console. We should prevent that, and test that you can't log in with invalid stuff.

That's not correct - apparently useraccounts enforces it for you! Wow.

https://github.com/meteor-useraccounts/core/blob/master/Guide.md#disabling-client-side-accounts-creation

@splendido, can you help me understand more about exactly what useraccounts is guaranteed to enforce?

Why are todoItems re-rendering when `list.incompleteCount` changes?

@avital and @stubailo (bringing this over from slack as this seems a more persistent place).

I'm looking at solving this problem a different way (using MM {fields}), but as it turns out, the problem has re-appeared in this repo somehow, even though AFAICT we are still following the same pattern of using {{#with list._id}}.

I can't for the life of me figure out what's different. I've played around with it a bit. Perhaps one of you two can figure it out easily?

here's your original commit to fix it: meteor/meteor@2e425df

Launch Screen hold on first fade in

For now I've replaced the uihooks with a simple momentum fade, but we should talk about why the hold was there before.

Usually the insertElement callback wouldn't fire when the thing was first rendered, so we should investigate what's going on in vanilla todos.

Audit filenames to be the same as the export, one export per file

Ensure our pattern for redirecting after async operations is correct

Figure out how to disable allow/deny

This can be as simple as adding deny rules for every collection

Use momentum for p->p animations

Use Autoform

Set up basic rate limiting with DDP rate limiter

How does this interact with useraccounts?

Accounts status message from useraccounts is ugly

We should make it look like the warning message, but green.

File tasks from today's meeting

https://github.com/meteor/guide/blob/master/meeting-notes.md#splitting-up-tasks-for-the-todos-example-app

Figure out how to make `listsShow` properly pure?

It's challenging to do right now, and in fact isn't super necessary because we can use StubCollections to test it properly anyway.

But it does violate a couple of principles:

• That components should be pure where possible
• That the data should be fetched at the same place where it is subscribed to.

We could pass the list and todos into it though. The main issue is the performance (re-rendering of all todo items when you check an item off). Still need to resolve that.

Denormalize userId onto Todos collection

So that we can do better authorization and avoid fetching the List for every todo operation.

Don't expose collections directly

Collections - don't expose the collection directly, have an API for talking to it in case you need to change the schema or guarantees later

Use Simple Schema + Collection 2 properly

• Get it working
• collection helpers
• Factories
• Unit tests
• Define + use Meteor.ValidationError
• Update SS to throw like check
• Update C2 to subclass

Figure out how to handle UI strings that come from DDP errors

Should we use i18n? Should we just hard-code the errors on the server?

Use Methods package / remove allow deny code