okturtles / group-income Goto Github PK

Either via a modal or via a new page, we need a way to log the user in, and then a button to log them out.

At some point we should also go over how we're taking your markup and integrating it with the build system and Vue js. There are some things that would make that simpler for us to do (like not having special classes on the body tag, not having special "padding" in general, or at least make it consistent across all .html files so that class variables can be replaced with template strings like {{page-class}} to templatify the whole thing).

Problem

Babel recommends against using transform-runtime/babel-register and against using babel-node in production.

Solution

Instead we should have grunt dist generate a dist/backend/server.js file and run that with plain old node (and moving what's currently in dist/ into dist/frontend).

EDIT: see this!

See also: #73 — Start moving project over to Node 7

Check out the handy list of links here: https://github.com/okTurtles/group-income-simple/wiki/Architecture-Notes#misc-useful-things

Bulma is based on flexbox and seems quite awesome:

• http://bulma.io

/cc @brodeur

Problem

Without being able to use async/await JS code can get unwieldy. We have support for babel everywhere except ejs templates (I think?).

Solution

vueify gives an example of how to do this. it's pretty simple:

var options = require('./options')
var babel = require('babel-core')

module.exports = function (raw, cb) {
  try {
    var res = babel.transform(raw, options.babel || {})
  } catch (err) {
    return cb(err)
  }
  cb(null, res.code)
}

preparse the templates and replace what's inside the delimiters with the output of babel, then pass it to ejs.

Requires some hack-foo while we're using Gruntfile.js (see #23).

Instead of:

      .catch(function (err) {
        logger(err)
        reply(err)
      })

Do:

      .catch(function (err) {
        logger(err)
        reply(ErrToBoom.badRequest(err))
      })

Per: http://hapijs.com/api/#error-transformation

Already did this for user.js, just needs to be done everywhere else.

Convert assert usage to should.

EDIT: we don't need to convert the existing stuff. assert is perfectly fine and actually has an elegance to it. Might only use should where assert is less elegant.

See TODO in user.js

1. test/index.js manually sets PORT = 3000 instead of reading it in from env vars or getting it as a default from some central place
2. Decide whether to stick with dotenv or not (#4).
3. index.js has server.connection({port: 3000})

Problem

People aren't telepathic.

Solution

Draft description of "Group Income Simple" for the About page. Explain what's similar to and different from Group Income.

Problem

Dependencies can be taken offline (availability) or become compromised (security).

See: okTurtles/dnschain#175

Solution

We can create forks of all dependencies we use, and also reference them by git hash. Also, we can use Yarn (#120), and we "shrinkwrap" them (i.e. simply put them in this repo).

Look through dist/app.js for things we don't need or could easily replace with something else.

Off-hand I'm noticing:

• bluebird
• jquery

Obviously minifying the app.js file will help to reduce line count too.

Problem

• it's unclear how to log errors properly
• on travis it's too verbose
• needs colors

Solution

• See official Hapi.js logging documentation
• investigate hapi plugins for better logging, like poop and good-console (see log rotation example)
• replace all calls to console.error / console.log with some decent library (the Good of Hapi? Winston?)

EDIT:

• See Pino and popular debug logging libraries, very fast
• bunyan was also recommended here and while it's not as fast as pino or debug, it's faster than winston

Low-hanging fruit, should be simple. If you don't have time for this feel free to assign to me, but it's probably less than 30 minutes of work.

Basically make npm test be an alias for grunt test (via package.json), and have it:

• run standard (just add a call to 'standard' in the array for grunt.registerTask)
• run test/index.js, which should launch the API server (just like DNSChain's test files launch a DNSChain instance) so that when grunt test is invoked all the tests work without having to run any other command from the terminal

Potentially useful:

• https://github.com/bclinkinbeard/partialify - require HTML/CSS and other text files. Can then potentially manually search/replace
• https://github.com/JohnPostlethwait/stringify - like partialify but seems more powerful?

Problem

It's insecure to download and run random code form the net.

Solution

Ideally, a simple way to chroot/sandbox it by specifying:

• what folder it's restricted to
• whitelisting resources it needs outside of that folder

something like containers/docker/unikernels.

• https://www.chromium.org/developers/design-documents/sandbox/osx-sandboxing-design
• https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/sandbox-exec.1.html

See if it's possible to design project such that it's a requirement to develop using the sandbox (i.e. project won't function/run otherwise).

Problem

We're not sure what the best way for distributing funds (that works, & meets member needs and local laws) will be.

Solution

Define what the user experience will be in terms of sending money.

• Should groups have a monthly meeting/party?
• Should groups appoint a treasurer?
• Will there be a central server with API keys? (carefully balance security and convenience)
• etc.

This issue is somewhat related to #37.

• Use grunt-webpack

• See webpack for browserify users (and browserify for webpack users)

• Get the component hot-reload thing working

• Ensure it's simple to switch back to browserify

• Make a note of the browserify and webpack related dev dependencies in a wiki, then replace the browserify deps with webpack equivalents

  Webpack dependencies: npm i -D grunt-webpack babel-loader css-loader ejs-html-loader vue-html-loader vue-style-loader vue-loader webpack webpack-dev-server

• Make it clear how "vendor" related JS (i.e. jquery, modernizer, etc.) gets added and used by the project

Either in a Wiki or frontend/simple/README.md (and linked to from README.md) add docs explaining:

• What files are relevant to designers
• Where designers should create new files
• How ejs/vue files work
• How the page title is updated via main.js (consider creating an issue to create an isolated and easier-to-edit routes.js file)
• How resources (images, css, vendor js) etc. are added to the project and loaded
• Table of contents at the very top and for the Architecture Stack Overview section.

See:

• http://forum.vuejs.org/topic/563/how-can-i-access-a-child-router-views-data-in-a-parent-component/11
• this other method seems not as elegant and doesn't work for me anyway

Problem

HTTP(S) is an insecure mess.

Solution

• https://securityheaders.io/

Make sure the website does all the CORS / same origin stuff especially!

• Use hapi to add CORS to API requests! http://hapijs.com/api/#serverrouteoptions

Useful plugins:

• https://github.com/nlf/blankie - A plugin that makes Content-Security-Policy headers easy
• https://github.com/hapijs/crumb - CSRF crumb generation and validation for hapi

Useful libraries:

• https://github.com/TypeError/blockade - generates headers for a variety of frameworks

Misc:

• https://pokeinthe.io/2016/04/09/black-icons-with-svg-and-csp/
• https://www.perimeterx.com/tech-blog/2020/whatsapp-fs-read-vuln-disclosure/

It's super annoying that Grunt doesn't support ES6 cleanly yet (hacks are needed). We need es6 support in grunt (via babel) in order to use async/await syntax in the tests.

• List of gulp plugins (for example, searching for "server" reveals three useful projects)
• Useful getting started docs
• Resources
• Example gulpfile.babel.js

Depends on #8.

Problem

Dependencies go out of date and some are security issues are discovered.

Solution

• https://github.com/RetireJS/retire.js
• https://github.com/bekk/grunt-retire

Benchmark the site and see how much is transferred. If it's not much this isn't necessary, but if it is then this needs to be done.

See: https://vuejs.github.io/vue-router/en/lazy.html

It's more elegant in Webpack (#44) to do this, but it can be done with browserify too (just involves an extra .json file).

Problem

We'll at some point need to be able to deploy GI to a running server.

Solution

Background:

• Right now we have grunt dev as the only way of serving the app.
• We also have an open issue for chel serve which is the ideal way that this issue would be closed
• A temporary alternative to chel serve would be implementing grunt serve - the idea of which would be to serve an optimized production build of the app.

I think whether we do chel serve or grunt serve first, we need a command to generate a build of the app that is production optimized. Currently we only generate a development build.

So a possible route forward would be to:

• Implement a grunt deploy command that uses esbuild to create a production bundle of the app
• Then implement grunt serve <folder> that just runs the server on port 8000 by default (and not browsersync). Make sure to take into account the contracts folder (perhaps grunt deploy would copy the contracts folder into a directory containing the groupincome bundle).
  • Note: chel serve is essentially the same thing, but more difficult to implement because the chel command doesn't have the Chelonia server in it (that's still here in Group Income under the backend/ folder)

Old Commentary/notes

See:

• http://vuejs.org/guide/application.html#Deploying_for_Production
• https://github.com/hughsk/envify
• excellent: https://gist.github.com/rauchg/8199de60db48026a6670620a1c33b700#production-optimizations
• Related issue: #41

EDIT: Another possibility is making it possible install a groupincome command via npm install -g and running that.

The point is our current approach of running grunt dev is not appropriate for deploying to a server, and we need something simpler and without the overhead of grunt dev.

Problem

Differences between "Group Income Simple" (GIS) and "Group Income" (GI) will impact the tests of GIS.

Solution

Brainstorm and document differences between GIS and GI. Where possible and feasible, include suggestions of how to adjust GIS to be as close to GI as possible

We can start looking into this once we've got the components finished — #6

This issue can be easily split up among multiple people.

First we should make a survey of all of the components to be extracted out of the HTML and into .vue files (i.e. make a list here), and then have at it!

EDIT: Many of these components are too simple to be worth creating .vue files out of. For those we just stick to the regular old markup and ignore (unless there's an obvious reason not to) the idea of making Vue components out of them. These I've marked, for now at least, "TOO SIMPLE — SKIP!"

For now we will use .vue files primarily as pages. Only if it meaningfully improves the markup should we be spending our times creating components out of things that are already effectively components (like <button>). It may even be worth considering avoiding the use of Vue.js and simply relaying on the Hapi backend to render template-based views directly (that would mean serving "normal" HTML files instead of this tiny skeleton). I've created issue #6 for this purpose.

Here are the components I've isolated:

• Green Button TOO SIMPLE — SKIP!

• Custom input field TOO SIMPLE — SKIP!

Note that as per new-user.html it can have a $ at the start and an optional image in the description!

• Panel

This is made up of the above components!

It should also be flexible enough to look like the box on user-profile.html!

• Small buttons (these are a component themselves) + Payment row (made up of them and other things)

• The weird payments tally widget sidebar thing on the left of pay-group.html

Problem

We don't know for certain what UX for payments groups will like best.

Solution

Set up a trial of various payment structures:

• all members receive universal payment (like UBI)
• only some members send payments (to individuals or to group pot) and only some members receive payments (like initial GIS draft)
• ?

Problem

We need to be able to signify that people are using a version of Group Income that we plan on significantly changing.

Solution

The site needs to clearly distinguish between the two versions, and on the about page (#7) we can have a blurb explaining the difference.

  server.auth.strategy('cookie_strategy', 'cookie', {
    password: 'abcdef',
    cookie: 'group-income-simple',
    ttl: 2592000000, // 1 month
    isSecure: false // HTTP allowed
  })

What's the reason isSecure is set to false there?

Related to #1, however until @brodeur is back we can just hack something dirty/ugly based on his existing work.

• https://github.com/karma-runner/karma
• https://github.com/assaf/zombie

gr2m/hapi-cors-headers#2 (comment)

So, I get the part about the security issue, but why isn't it a simple config option in Hapi to say: allowedDomains: ['domain1.com', 'domain2.com']?

Problem

Requiring modules will import all of their code when sometimes you only need a fraction. This bloats and slows the app.

Solution

• https://github.com/nolanlawson/rollupify

Main issue is slowness. See: standard/standard#459

Problem

People use radically different resolution displays, and assets that look good on one don't look good on the other.

Solution

• https://imulus.github.io/retinajs/
• resolution independent formats like svg

Per convo with @SGrondin and @dotmacro, GPL is compatible with MPL 2.0 and more appropriate for this sort of project.

• https://github.com/egoist/revue
• https://github.com/vuejs/vuex
• https://github.com/vuejs/vue-resource
• https://github.com/vuejs/vue-devtools
  • figure out why it's not working: vuejs/devtools#62 (comment)

most of these from http://vuejs.org/guide/application.html

• Make tests not pollute/conflict with an existing database data
• Make tests clean up after themselves so that you can run grunt test (#8) multiple times

• Use loadjs (or code based on it) to remove the hackish "waitfor" stuff. See also if you can get the script2's to execute in order specified in the HTML
• Use a global promise object to serialize the loading/running of scripts in the order they appear on the page
• figure out whether we're keeping the unloading feature? seems handy.
• Vue 2.0 deprecates elementDirective, so see if script2 can be done as a component
• update docs accordingly
• consider switching to Riot or at least mentioning it in the docs

Useful libraries:

• https://github.com/muicss/loadjs <- this is the best (it's an improved version of script.js)
• https://github.com/ded/script.js !
• https://github.com/tomek-f/simple-load-script
• https://github.com/kabirbaidhya/get-js
• https://github.com/matthiasak/Loader/blob/master/loader.js#L266-L280
• https://github.com/systemjs/systemjs/blob/master/lib/scriptLoader.js

Useful links:

• http://unixpapa.com/js/dyna.html
• http://www.html5rocks.com/en/tutorials/speed/script-loading/

https://github.com/okTurtles/group-income-simple/blob/greg/frontend/simple/js/Script2.js

Problem

There are TODOs in the code that need to-doing to to-get-rid-of-ing.

Solution

• Create issues out of them
• Delete them
• Or leave them for later

EJS currently doesn't work within .vue files, which isn't a big deal but would be neat if it did:

<template lang="ejs">
  <div><%- include views/included %></div>
<template>

Corresponding issue in vue-loader: vuejs/vue-loader#197

Note: if views/included.ejs is modified and saved the change might not propagate through webpack-dev-server (which we aren't using atm, so might not be an issue).

See http://hapijs.com/tutorials/views + new edits to #6.

Hapi's vision plugin homepage has great examples of how to set this up and what templating languages are supported.

Tasks

• Figure out whether (and how) we should make the site both CDN-friendly (i.e. keeping it deliverable as purely static files) and designer-friendly. On-the-fly rendering of the front-end markup using EJS via Hapi is not a good long-term solution. Maybe the right thing to do is to render/compile the EJS templates to static .html files like jekyll does it?
• Remove any .vue files that are unneeded.