backstopmedia / hubbub Goto Github PK

Button to refresh the issues from the added repos.

Should be able to take care of this 1/19

Just to order them. Probably not necessary, so we can gauge based on our progress and the complexity of the app. Thoughts?

I'll work on this bit once the app is the complete. We can use targethtml and grunt to produce a standalone production-ready build.

I'm interested in creating a plugin version of this project using backbone-boilerplate and layoutmanager. Should this be a fork or in a branch? TodoMVC route where different options are included?

app.Sidebar is getting a bit big and confusing.

At the moment, clicking back in the browser leaves the modal open.

looks like we're only showing the first few repos per organization. pagination?

I'm interested in working on this, but anyone else who wants to contribute.

Good example to show off _.throttle() or _.debounce().

Wanna see our traffic.

Wouldn't they just close the issue on Github instead? Not sure about the best way to handle this, UI-wise. Thoughts?

User should be able to see repos from any Github user to select issues from. Replaces #5.

We should remove json2 not really relevant. We can make a comment on it in the book.

As this is an example app, perhaps we could have a view which would be position at the bottom of the screen which would be an event log. We could listen to all events on all the views / models / collections and log it to this view. This could perhaps help people new to Backbone understand a bit more about when different events are fired. The view could be hidden by the user if needed.

Here are some suggestions for starters:

1. Welcome
2. Main Dashboard - to view, filter and manage issues
3. Manage Repos - to add / remove repos to track
4. Edit Issue (should this be a modal dialog like trello?)

It's confusing with a mix of app.User objects and anonymous user objects under the issues and repos. I think we should go all the way (with some relation plugin), or just take out this model. The only place it's used

var user = new app.User({login: match[1]});
this.findReposFor(user);

can be refactored to

app.Repo.Collection.findByUsername(match[1]);

I don't think we want to display this as a separate page (see prior discussion in #16). Added a mockup in Mockflow.

I tend towards brevity/laziness in my inline comments and often use lowercase phrases - seems others use proper capitalized sentences. We should make this consistent throughout the repo. I'm fine either way. Votes?

Currently the app resets on every page refresh.

Should be able to select an issue and set it as "To Do", "Complete", or "Done".

some of the tests are broken...

More common term.

This would save a click 👍 Thoughts?

We want a boilerplate project that readers can fork, clone and start work from. This can either be a separate repo, or a specific branch in this repo (master, probably?). For the latter, we can move our development to a branch called completed. Any thoughts?

Here's what I'm thinking:

• On first visit, ask for Github username to pull in their repos (see #5)
• Provide a way to view the issues (or at least issue titles) from each of their repos
  • This will be a lot less interesting for new-er programmers with few repos.
• Provide way to organize the issues from the various repos
  • Separate "To Do", "In Progress" and "Done" lists, Kanban-style?
  • Single long re-orderable list?
  • How do issues get moved around? Draggable is my first instinct, but that could introduce some complexity with jQuery UI or whatever.
• Minimum issue display:
  • Show issue title, repo name and issue number
  • Link to open it on Github

I'll handle this one.

Probably a little 'X' next to each one.

We use this technique in our framework at @Jux: create a special Collection that contains all instantiated Models, so that if you try to create a new Model with the same 'id' as an existing one, it just gives back that same instance. Has saved a lot of headaches, but I know this isn't necessarily a common Backbone pattern.

This is a backbone best practice.

I use this in a project I'm working on

(function () {
  'use strict';

  var $ = window.jQuery;
  var app = window.app;
  var Backbone = window.Backbone;

  app.ListView = Backbone.View.extend({
    initialize: function () {
      this.views = {};
      this.listenTo(this.collection, {
        add: this.addModel,
        sort: this.sortModels,
        remove: this.removeModel
      });
    },

    addModel: function (model) {
      this.$el.append((this.views[model.cid] = new this.options.ModelView({
        collection: this.collection,
        model: model
      })).el);
    },

    sortModels: function () {
      var views = this.views;
      var $el = this.$el;
      var $models = $el.children();
      this.collection.each(function (model, i) {
        var el = views[model.cid].el;
        if (!$models[i]) {
          $el.append(el);
        } else if ($models[i] !== el) {
          $models.eq(i).before(el);
          $models = $($models.get().splice(i, 0, el));
        }
      });
    },

    removeModel: function (model) {
      delete this.views[model.cid];
    }
  });
})();

Then we can use the app.ListView to display the results.

We don't have to spend time explaining it in the book, but would be cool to have a branch where we fully leverage community-built plugins and to show how much of the cruft could be cut out. We can link to the branch/compare view from the book/README, just as a demonstration.

Plugins to be included, for starters:

• LayoutManager
• Backbone-Super
• something for associations/relations

Or did someone intentionally remove it?

GitHub's API request rate limit is only 60 per hour. In light of this, I think we need to cache vigorously. Fortunately, all of the CRUD operations are set up for localStorage so we can save/fetch/destroy for free (basically), synchronously. I've set up the app so far to save repos and the repo's issues when they are added to app.board in the side panel view. This way, when we load up the page again all the data is pulled locally. I think we should make all GitHub API requests explicit opt-ins from UI interactions (i.e. "click to fetch new data"). If we start doing automatic remote fetches, however convenient it might be for certain parts of the app, we're going to hit that limit very quickly.

Not to totally re-create a myriad of plugins, but what if we had an addChildView() method in our app.View class, and overrode the remove() method there to clean them up? Or is this over-engineering for this app we want to show the basics?

Work started in backbone-1.0.0 branch - I'm seeing the same failure in the tests and the app itself, around Board.Model#parse().

complete...backbone-1.0.0

Make a base app.Modal View - can be a good example for inheritance.

...so we know whose repos/issues to pull. User switching not a requirement for the MVP :-)

Lets try and figure this out 💃

Route methods shouldn't be calling one another. I would go so far as to say that the Router should barely have any code in it: just call methods on the app to set up the appropriate state.