alloy / relational-theory Goto Github PK

From #19

For bigger projects I'd encourage a modular architecture. E.g. what we do in Force/MG where you have sub-apps and a components directories that make it easy to say "fork" the artist page by copying the sub-app and splitting between the two at a routing level. The co-location of files also makes it easy to experiment and drop old code. I also think this provides obvious "escape hatches" for when one finds themselves fighting the React/Relay/etc. stack, e.g. they could implement a sub-app that does more vanilla Express stuff or introduces a new approach to UI suited to that edge case need.

Not sure an issue is the right format to leave my thoughts on this, but I'll quickly jot them down here:

• Firstly, this is awesome—I very much support the direction this is going
• Not something for now, but opportunity for later—we could probably wrap up a fair bit of boilerplate in modules/framework-ey stuff. For instance, there's a lot of noise here to basically say "render a component on the #root element".
• These HTML strings are kinda ugly, could we use stateless react components instead?
• For bigger projects I'd encourage a modular architecture. E.g. what we do in Force/MG where you have sub-apps and a components directories that make it easy to say "fork" the artist page by copying the sub-app and splitting between the two at a routing level. The co-location of files also makes it easy to experiment and drop old code. I also think this provides obvious "escape hatches" for when one finds themselves fighting the React/Relay/etc. stack, e.g. they could implement a sub-app that does more vanilla Express stuff or introduces a new approach to UI suited to that edge case need.
• Might go without saying, but config like this should be moved to environment variables and a .env file
• Be careful with doing universal stuff with Webpack, because some of the Webpack loader features can make server-side rendering a pain
• It might be good to be able to toggle off hot module loading (e.g. with an env var), b/c it can get kinda magical and full of edge cases (ideally we'd avoid having if (module.hot) clutter the code too)
• It'll be interesting to see how the testing story shapes up after some of the architecture settles
• Eventually would be good to include docs on the whole VSCode/tooling setup
• I need to spend more time with Relay, but I wonder what a more client-side complex app will look like and how one would manage "application state" over the data fetching story. I'm also curious how much value we're getting out of Relay when we expect to mainly do server-side rendering—which I expect would typically involve pretty simple fetch().then(() => res.send(ReactComponent)) code. I guess the component portability/static analysis?
• Have we considered any universal routing solutions like React Router (not suggesting it, just curious)?

👍 👍 👍 exciting stuff!!

I decided that I do want to see how source compatible components could be between web and mobile, so I’ve started porting some Emission components. #16

The universal/rehydratio issues should be solvable. In fact, there’s a PR up that switches the underlying styling lib to JSS, which I have already verified to work well in a universal app. necolas/react-native-web#304

This is something handled by a Haste Map in Jest.

That said - flow does have something for this:

npm run flow -- get-imports app/containers/artist/index.js

> [email protected] flow /Users/orta/dev/js/apps/relational-theory
> flow "get-imports" "app/containers/artist/index.js"

Imports for module 'app/containers/artist/index.js':
	/Users/orta/dev/js/apps/relational-theory/data/graphql-export.flow.js@/Users/orta/dev/js/apps/relational-theory/app/containers/artist/index.js:6:33,6:67
	/Users/orta/dev/js/apps/relational-theory/app/containers/artist/components/header.js@/Users/orta/dev/js/apps/relational-theory/app/containers/artist/index.js:5:26,5:46
	react-relay@/Users/orta/dev/js/apps/relational-theory/app/containers/artist/index.js:4:19,4:31
	react@/Users/orta/dev/js/apps/relational-theory/app/containers/artist/index.js:13:7,13:11

The way we currently embed the Relay data of the server-side fetch into the rendered html is unsafe and could open us up to a user embedding html into our data that then could be used as an attack vector.

This tool does the job, but there might be an even simpler alternative https://github.com/yahoo/serialize-javascript