Improving Code Quality / Approachability

[ceane]

I really like this library, however it's just 1 file and well over 5000 lines long. Do you have plans to break things up into Common JS modules, add JSDoc comments and code quality tools?

It'd be really nice also there were natural hooks for other frameworks and libraries (i.e custom mixin for React or Angular module).

[taye]

I really like this library, however it's just 1 file and well over 5000 lines long. Do you have plans to break things up into Common JS modules, add JSDoc comments and code quality tools?

Yes, I plan to break things up but I don't plan on putting things into modules.

I'm not sure about using JSDoc. I had been using it initially but I didn't feel that the generated docs worked well for interact.js' API, but I probably wasn't using it correctly. If you or anyone else would like to convert some or all of the dr.js comments to JSDoc and the results are good then I'd probably be willing to switch back although I would miss the prettiness of the current dr.js output :<

As for code quality tools: I use Tern for vim and Syntastic which work quite well. I guess I could add the .jshintrc file that I use into the repo. What else would you suggest?

It'd be really nice also there were natural hooks for other frameworks and libraries (i.e custom mixin for React or Angular module).

What sort of hooks do you mean? I've never tried React and I've only barely looked at Angular so I don't know how integration with those might go. However, I think that it should be straight forward, given what interact.js provides.

If you have any other suggestions, recommendations or arguments, please share them.

[ceane]

What I mean by modules is your library's structure could look like this (sort of how React is structured):

src/
  core/
    Interact.js -- the main module that links in the bundles
    InteractEvent.js
    Interaction.js
    Listener.js
    Interactable.js
    ..etc

And a build process (either webpack, browserify, etc) would bundle all the modules together to one file and either provide a CommonJS module (require('interact')) or just a global var as it is now.

---

I'm not sure about using JSDoc.

Well your docs are fine, ignore my comments about JSDoc. I didn't look too hard at all of the methods to see the annotations.

---

I suggest, for now, adding CodeClimate and Travis. In the package.json, add this for Travis

{
  "devDependencies": {
    "chai": "*",
    "mocha": "*"
  },
  "scripts": {
    "test": "WHATEVER COMMANDS YOU ARE USING TO TEST" 
  }
}

For integration with CodeClimate, I recommend a .jshintrc file, otherwise it gets pretty crabby about minor things.

---

What sort of hooks do you mean?

These are both simple examples of what I mean by hooking into Angular and React. Perhaps I could have working examples soon.

Angular service React mixin

With React it would be straight forward, so it could be used like:

//Using jsx here, <div /> compiles to React.DOM.div()

var DraggableComponent = React.createClass({
   mixins: [InteractMixin],
   render: function() {
     return <div />
   }
});

React.render(<DraggableComponent draggable="true">, document.body);

[taye]

What I mean by modules is your library's structure could look like this (sort of how React is structured):

That looks good. Did you also mean that each of those files would be defined as an individual module CommonJS/AMD module (but would be compiled into one seamless file)?

And a build process (either webpack, browserify, etc) would bundle all the modules together to one file and either provide a CommonJS module (require('interact')) or just a global var as it is now.

AMD and Node module definition is currently done with fall back to a global variable.

I suggest, for now, adding CodeClimate and Travis. In the package.json, add this for Travis

The present automated tests are no good. I've just been using smoke tests and I need to fix that. Splitting the file up should make it easier.

For integration with CodeClimate, I recommend a .jshintrc file, otherwise it gets pretty crabby about minor things.

Code climate unsurprisingly gave me an F :disappointed:. I think I'll leave the badge out of the readme for now.

These are both simple examples of what I mean by hooking into Angular and React. Perhaps I could have working examples soon.

Those seem good so far. If you work on those I could add references to them in the readme.

[natew]

Just want to say this library really caught my eye. I'm working on a mobile UI kit right now and the biggest piece I've been hesitating on has been interactions. For now I'm using popham's fork of the Zynga scroller, and avoiding dragging.

This library seems pretty well written, though the syntax is a little weird. But I will say I think the biggest downside for me at the moment is the structure.

Using webpack with a module system would be a huge benefit for npm users. It would allow people to pick and choose pieces of your library to use without having to load the whole thing. It would also probably force you to keep strict separation of concerns when it comes to syntax.

Anyway, it seems like there's a lot of movement in this area, and I'm still unsure which way I'll go. I do really like facebook's rebound.js stuff for it's physics. My first test will be rebuilding that scroller library using some physics based interactions, but I'd love to use at least a few pieces of this repo in there as well.

All this to say, :+1:

[taye]

This library seems pretty well written, though the syntax is a little weird. But I will say I think the biggest downside for me at the moment is the structure.

I'm working on improving the syntax and I've listed related issues in #88. If you have anything you'd like to add, I'd really appreciate a comment there or a new issue.

Using webpack with a module system would be a huge benefit for npm users. It would allow people to pick and choose pieces of your library to use without having to load the whole thing. It would also probably force you to keep strict separation of concerns when it comes to syntax.

Yeah, I realised that this would be the better way to do things after trying very roughly to split the project into multiple files.

I'd like to fix some of the issues listed in #88 before I really start the separation.

I do really like facebook's rebound.js stuff for it's physics.

I didn't know about rebound.js. It looks like it could really improve snapping, restriction and inertia.

All this to say, :+1:

<3

[tedvanderveen]

@Ceane: did you have a chance to dive into AngularJS (event) integration? What would be a prefered way forward? Using Services and/or Directives?

[ceane]

@tedvanderveen I have not. With Angular 2 changes, I would like to work on something that can be used between the newer and older versions. Starting with services would be the right way and then in the future adding directives for specific animations would be good. Maybe ignoring that Angular exists would be the way to go.

[tedvanderveen]

Indeed, that's exactly what I ended up doing, an Angular service with all Interactjs specific implementations, using Angular for the initial one-way binding of the template. Thanks!

[stephen-james]

@taye firstly thanks for an awesome library, really really good and has helped me loads. I would be keen to help split it up into microlibraries / modules to allow for devs to only require the bits they need, so please ping me if you are wanting to go this direction and would like a hand. I'm @stephenhjames on twitter.

[taye]

@stephen-james Thank you! I'd really appreciate it. I should have time to discuss it with you this some time this weekend. I think a private chat on Gitter would be the easiest way. I'll let you know when I'm free.

[stephen-james]

@taye, great! I'm signed in to Gitter app so hopefully will get notifications when you shout