oliverbarnes / old-participate-client Goto Github PK

Backend already supports it, implement interface

Once an initiative is posted with a new issue, this issue is open for alternative initiatives.

When viewing an issue, clicking 'Add another initiative' takes you to the initiative form, pre-populated with the issue title.

Ember 2.0 is moving towards a React-like approach where everything is component, doing away with all the confusion around controllers, where to put actions, etc.

It'll be available starting with ember 1.12:

We plan to land support for routeable components in Ember 1.12, and deprecate routeable controllers at the same time. We plan to remove support for routeable controllers in Ember 2.0. This will allow you to move your codebases over to routeable components piecemeal before making the jump to 2.0.

Some WIP tests are breaking it

Implement interface, there's already an endpoint for this on the api.

On an existing initiative, clicking on a link to 'Make a suggestion' opens up a text area to be submitted. The suggestion gets associated with the initiative.

Like comments on a blog post.

With updates on proposals, supports, suggestions, delegations et al once they're implemented

As we discuss it over on Slack, it's becoming clear it can be done in different ways, different scenarios:

• while looking at the list of issues, clicking in one of them to expand and view the description.
• visiting the url (or clicking on an link with that url) for an issue, and that render the issues list and scrolls to the issue, highlighting and expanding it (edited)

We probably will have other ones come up. looking at an issue from an initiative, for instance. we can all add the new scenarios to the github issues as we discover them.

The first scenario above, "looking at the list of issues, clicking in one of them to expand and view the description" seems the best one to focus on now. it's simpler and a natural extension to browsing the list of issues

As discussed with @miika yesterday night, it can be done in a emberish way by using a specific route for the issue, within the list. this would involve changing the url (transitioning to the specific route), and that makes sense from a UX perspective as well. Highlighting it visually might make sense as well, as an extra feedback to the user..

This is the reference I sent @miika last night (see last tip "Toggling properties"): http://say26.com/five-useful-tips-for-ember-js-developers

Some code to illustrate what I'm thinking (not tested, and doesn't include the highlight logic):

//router.js
Router.map(function() {
  this.resource('issues', function() {
    this.resource('issue', { path: ':issue_id' })
  });
});

//routes/issue.js
var issueRoute = Ember.Route.extend({
  showDescription: false
});

//templates/issue.emblem
.issue click="toggleProperty 'showDescription'" 
  .title Global warming
  .description visible="showDescription"
    p The end of the world

More about binding actions in emblem at the "Action / Events Shorthand" of the syntax docs: http://emblemjs.com/syntax/

when users click "Remove support for this initiative", there should be some alert appears to reminding the users.

Simple and oAuth (Facebook, Twitter)

We need to figure out which library to use, and this depends on compatibility with Ember 2.0

While working on the supporting a proposal story, the need to have a current user set popped-up. The API doesn't have a current_user yet, only a current_login - I was leaving to implement it at the last moment it was needed, since it involves modeling the user (probably a Participant, like @williamcodes suggested), and it'll affect all user-specific interactions like delegating supports and votes, and following another user.

So far I've come across these references:

• http://blog.willrax.com/fetching-the-current-user-with-simple-auth/
• http://discuss.emberjs.com/t/best-practice-for-loading-and-persisting-current-user-in-an-authenticated-system/6987/9
• https://github.com/simplabs/ember-simple-auth/blob/master/examples/4-authenticated-account.html

I'll probably follow the last one, since it's ember-simple-auth's author's recommended path

The API is moving towards the JSON-API standard, and Ember has this adapter to consume it

Good first feature to start with. Will start on it as soon as the testing framework is in place

WIP: https://github.com/oliverbarnes/participate-frontend/compare/validations?expand=1

Similar to #11 - can't get to the appended text ("can't be blank" et al). Tutes seem to avoid this part.

On master branch, going to initiatives/1/suggestions only shows one suggestion.
Going to initiatives/2/suggestions shows no suggestions.
Will submit a PR on branch suggestions-bug.

Looking at .tavis.yml, after installing everything which seems to be needed I got the error below.
I see travis is also failing for a long time.
$ npm test

[email protected] test /home/mag/project/Alkotmany/participate-frontend
ember test

version: 0.1.4
Could not find watchman, falling back to NodeWatcher for file system events
Building...
Cannot find module 'ember-cli/lib/broccoli/ember-app'
Error: Cannot find module 'ember-cli/lib/broccoli/ember-app'
at Function.Module._resolveFilename (module.js:338:15)
at Function.Module._load (module.js:280:25)
at Module.require (module.js:364:17)
at require (module.js:380:17)
at Object. (/home/mag/project/Alkotmany/participate-frontend/Brocfile.js:3:16)
at Module._compile (module.js:456:26)
at Object.Module._extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.require (module.js:364:17)
at require (module.js:380:17)
at Object.loadBrocfile (/usr/lib/node_modules/ember-cli/node_modules/broccoli/lib/builder.js:147:14)
npm ERR! Test failed. See above for more details.
npm ERR! not ok code 0

adopted-ember-addons/ember-notify#7

Delegating your vote and support for areas and issues to another user

For consistent testing style in both front-end and api.

This is WIP, currently trying to get Mocha setup, following this experiment. Might have to try qunit-bdd though

Implement interface, backend already supports it

I'm thinking of renaming the participate-frontend to simply participate, it being the first point of contact with the project and where the interface lives, and the current participate repo to participate-api.

Seems a lot clearer to me this way. Any objections? If none, I might do this some time later today or tomorrow.

Test that previously ran fine barfs with this

ok 5 PhantomJS 1.9 - Supporting an initiative Successfully
not ok 6 PhantomJS 1.9 - Supporting an initiative "after each" hook
    ---
        message: >
            Assertion Failed: calling set on destroyed object
        stack: >
            Error: Assertion Failed: calling set on destroyed object

Seems like an async side effect from another test

Itemized deletion of suggestions.

It'd be nice to have the delete link appear when hovering the cursor over the suggestion, so it's not there at all times. Less noisy and helps focus on the content

Epic to be broken down into smaller user stories and tasks later.

Issues belong to areas like 'Housing', 'Healthcare', 'Transport/Mobility', 'Environment', etc.

When an issue is created, an area will have to be selected.

Once we have users on the system and vote delegation, users will be able to delegate to another based on area

Cathy found a bug on making a suggestion, when click "Support this initiative" then click "Make a suggestion", box and submit button show. BUT without clicking submit button(you can leave it empty or just type something in box), if you click "Remove support for this initiative", the box and submit button will show together with "Support this initiative". Normally box and button shouldn't show. In addition, if you click the "Support this initiative", the box and submit button will also show.

Also, after you submit suggestion and click"Remove support for this initiative", your suggestions will be shown together with "Support this initiative". If you remove support, suggestions normally shouldn't be shown.

Simple link 'Support this initiative' on a existing initiative's view.

Clicking it will change link to 'I support this', and save a support entry for the initiative.

Since we don't yet have authentication, no user will be associated with the support yet on this iteration.

when manually typing /initiatives/1/suggestions/new, it shows "support this initiatiative" together with the suggestion box and aubmit button. Users cannot make suggestion before they support initiatiave

Renders the issues list and scrolls to the issue, highlighting and expanding it. Url changes to /issues/:issue_id

when users click "Remove support for this initiative", suggestion posted by users before are also will be removed

Closed all issues from previous iteration, started out with this one, which is done

With Semaphore.

To get tests to run against pull requests, specially

This'll be a tricky one, EasyForm and Validations with a nested model

Not sure if it's too early to worry about this, but as I write the first acceptance test, I'm thinking it's good to have some standards for the way the html should be structured, so the tests and whoever is building the UI know what to expect.

Looking into using Bourbon with its scaffold styles, Bitters, as they look a lot cleaner than Bootstrap. There's a ember-cli addon available for Bourbon

For simple semantic forms, looking at Ember EasyForm. There's a more plug+play Ember Forms that uses Bootstrap, but both the template and output code look very messy

For code quality reports https://codeclimate.com

Similar as issue 25: viewing an issue , here is the link #25

(Epic) Basic support for users

• sign-up / sign-in
• listing users

Discussion on the mailing list

If I disagree with an initiative, I'd like to make a counter-proposal / alternative initiative

Clicking on a link to 'Propose an alternative initiative' takes me to the same form for creating an initiative, but populated with the original initiative's issue title.

The user flow I see for this

• viewing a proposal
• opting to delegate support
• selecting another user to delegate to

"Delegate" is a pretty formal word, wish I could find a friendlier/less formal one

eventually, I'd like to see something for quickly delegating support for proposals from the proposals list. On mobile, maybe touching and holding the touch until an option to delegate appears.