Switch to Flow Router

[asteroidb612]

After looking at #61, I ran into trouble getting the author, work, title, reading position we wanted without querying for the author and title using the work slug in the url and assuming part of the reading position.

I think we should instead have the entire reading section be a React component which passes this data to the reader and reading-location instead. We can mix such router-level React components with the Blaze templates on the rest of the site if we switch to Flow Router. It rather simply routes Blaze alongside React, shown here.

This lets us avoid using a state machine like Redux and we could still use the momentum transitions in the Blaze templates.

Thoughts?

[lukehollis]

Hey @asteroidb612, thanks for starting the conversation here. Needless to say, nailing down the shakedown between Iron or Flow router and Flux or Redux is going to be important. I was imagining that Redux might be useful for managing the state for the reading interface and the commentary, definitions, and translation panels as well as the other related media. It seems like we might be able to do more in the future with this but would add much more complexity to the project. What are your reasons for wanting to avoid it?

I'm open to either flow or iron but am not all the way understanding what you're saying the advantage of Flow over Iron would be. We definitely need to replace my poor bandaid workaround while I was working on the text syncing w/the api: https://github.com/cltk/cltk_frontend/blob/master/client/views/reading/reading.jsx#L13

[lukehollis]

@asteroidb612, I started migration to FlowRouter and merged with Meteor 1.3 upgrade branch. Excellent suggestion.

[lukehollis]

Now utilizing FlowRouter for the application