How should we build the React/Front-end side of the app

[benirose]

So I've done a ton of research on how React apps tend to get structured and the most common use case is for a Single Page App. My main concern around this was it creating a bunch of other unknowns for me, namely around authentication, but also around how much of the other stuff we'll need to learn (Redux, Flux, Stores, wwaaahhhht?!)

I did manage to find a library, React Habitat, that is made for just Reactifying some of your app, not replacing it with a single page app. The downside of this, as people say, is that React is a fairly large library, so adding it on every page serve might be a bit much. Of course caching happens, but I don't know how long it takes to boot up the library. Additionally, it seems somewhat hard to break apart the React code so that each page only loads in the components it's using. This is more extra code loading. In spite of these downsides, the path is pretty clear. You define all your components, and then in your template, you use mark up that will get replaced based on data-component and can pass in properties:

<div data-component="SomeReactComponent" 
    data-prop-title="A nice title"
    data-prop-showTitle="true"></div>

This, to me, is an easy method for connecting the node side to the react side.

Of course, this is not what 99% of React developers expect. The "proper" way is to build a single page app that hits an API, and there is no coordination between the two. My main complication with this was authentication, but after thinking more about it, we could just have the login happen outside of the SPA. In otherwords, /login would be the only other route (outside of the API) than the main app. This way we can login using a traditional method with sessions, and then be able to check against that session when API calls are made. It should be fairly straight forward from there, and comes with the bonus of being able to look at how a million other React apps are structured to get guidance. Also the build process is more straight forward.

So the question is, do we a) Do the thing no one really does because it feels more normal to what we're used to doing b) Do the thing everyone does, even though it's a steeper learning curve, but my main obstacle seems to be addressed.

[benirose]

Another thing worth mentioning is using React at all causes some search engine issues, unless you are rendering some of it on the Server, but Isomorphic JS is way out of my wheel house.

[prestoncabe]

hmmm... regarding your first comment.... from your explanation, it seems like choice b is going to be less pain in the long run. That's just my first impression.

Regarding SEO... that kind of sucks, I wasn't thinking about that. Warrants some discussion.

Are you reconsidering whether we should use React at all?

[prestoncabe]

looks like getting google to index things might be pretty easy? http://andrewhfarmer.com/react-seo/

(but doesn't account for other engines)

[prestoncabe]

what about this? https://facebook.github.io/react/docs/environments.html

[benirose]

I did consider if react is the right solution. It's definitely built for SPA use and many places highlight it's strength for apps where data is often updating. Neither of these are really applicable to our project.

The React homepage says: "React makes it painless to create interactive UIs. Design simple views for each state in your application, and React will efficiently update and render just the right components when your data changes." Most of that is relevant, but even at the end there it focuses on data changes.

EDIT: The "Why React" page on their website says "We built React to solve one problem: building large applications with data that changes over time."

With that said, I'm not sure what other options make sense, other than Angular (which I'm no interested in exploring). Backbone is really more along the lines of meeting our needs, but it's popularity is fading quickly. I think we should stick with React. I can try to push aside a lot of these questions and just focus on getting some stuff done in the mean time.

[benirose]

I think ideally the link you sent about environments is what we'd like to do, but that might take a lot more work and have a higher learning curve, so for now I'm going to focus on client side rendering.

[benirose]

I think part of the issue that has made this difficult for me is trying to learn the react stuff around the assumptions I have of what a node app should be, and figuring out how to merge that together.

I'm going to try a different approach of starting from the React side and building out from there. https://github.com/facebookincubator/create-react-app seems like a good place to start, and has a lot of info about how to build out from there, particularly with bootstrap and a node backend. I'll do some research this week and see where that gets us, I have a feeling it will be helpful, but if not, we can move forward with where we are.

[prestoncabe]

Okay cool. I was wondering about starting over from the React perspective as I was reading some stuff yesterday, so it seems like we are on the same page there.

[benirose]

Are you comfortable writing Javascript in ES6? I'm much more proficient in classic JS, but a lot of the React stuff and examples seem to be ES6.

[benirose]

OK, I spent a little time with create-react-app and it definitely helped clear some things up for me. I think I'm seeing a path towards getting this up and running. It may take some work to figure out what the right configuration options are, particularly for webpack but the vision is clear. My end goal is to:

-Build Single Page react app -Build API routes with session authentication -Have a single node server which serves both the client (react) app and the API -Have the node server render the client (react) app before serving (for speed and SEO)* -Have dev and build scripts for reloading locally and building for production

*I think, this is a stretch goal, but I can lay the groundwork for it now without much extra work

The main thing still left to work out is automated testing. Since we are trying to move forward, I vote we table that until we get 1.0 out the door. Writing tests for the API will be straightforward, and if I can solve for server side rendering of the react app, that may get us almost there.

[benirose]

Since the first item is to focus from the React/Client side of things, I'm wondering if we need to revisit #3 and our potential design in order to move this forward or if I should just go with what you've started and get the plumbing together, and we can rebuild the pages as we go.

[prestoncabe]

ES6 - I'm not comfortable writing JS period ;) , so my vote is to skip up to ES6, because of React examples using it (P.S. - Chrome 52 now supports ES6 natively!)

Vision/end goal: your plan seems sound at a glance.

Testing: yeah, writing tests (especially TDD) is hard when you're just trying to figure out how get started. Ignoring until after 1.0 is fine for me.

Song detail design: I don't know what's best. maybe something to discuss on Friday.

[benirose]

I've gotten to work a little on this over the past week and have made great progress. Additionally, I've been able to find a path toward a classically multipage app with React and server-side rendering. I think this will allow us to work within our comfort level while not doing something so wildly off the beaten path. I'll try to push up a version with at least the client side version of the song detail page and build process in place tomorrow.

[prestoncabe]

Somehow I didn't get the notification for your last comment.

Sounds awesome!

I'm looking forward to seeing what you've got.