I found something like this to be most flexible. /root ../src ../../client (entrypoint for client, rehydrates react tree/etc) ../../server (entrypoint for server, spins up db, express, etc) ../../blog .. /../ ../common (react components, graphql typedefs) .. /../ ../../components .. /../ ../../routes .. /../ ../server (graphql resolvers, other stuff that only runs on server) .. /../ ../../resolvers ../../user .. /../ ../common .. /../ ../../components .. /../ ../../routes .. /../ ../server (authentication logic, express middleware, gql resolvers for store, etc ) .. /../ ../client (browser cookie/local storage logic) ../../layout (sitewide react components, IE: PageHeader, NavBar, etc) ../../ui (reusable sitewide micro-components ie: Button, Modal) note: ./layout and ./ui don't have "server"/"common"/etc divisions because they purely in a single domain (common) so I just put their contents at the root instead of ./layout containing a single folder. Obviously it depends on the complexity of your site. But I find this allows me to seperate different aspects of the site (ie: a blog, and a user portal) and break them down into client/common/server. you probably end up with multiple folders named "client" or "common" in your tree but I think that's of minimal concern.

stfu bot

What framework/server are you using? Apollo, relay modern, etc? Also show me a little bit of your schema. I don't quite get what you mean.

#2 puts the nail in the coffin. DOA.

gaearon (Dan Abramov) sindresorhus (Sindre Sorhus)

The full source of my component can be found here: https://pastebin.com/dRY0Vsyd Let me warn you, this is written in TypeScript. Assuming you've only done JS in the past, you'll probably see some syntax you're not familiar with, just ignore it, it doesn't affect the way the code works, just gives you better type completions in your IDE. So the reason why I implement that function is to register/unregister event listeners that listen for the escape key as the user passes in different props. That's what componentWillReceiveProps is for, changing things you did in componentDidMount/componentWillMount based on changes to the props.

If you don't name the function that? or are you asking what if you don't call that function?

wireframe -- a quick sketch consisting of lines and/or zones mockup -- something "mocked up" ...lol in photoshop. A static graphic representation of what the finish product could look like. Usually not polished or containing anything more than lorem ipsum as far as content goes prototype -- something actually running on the intended platform. eg: a site at http://localhost:3000 or an app running in the emulator.

I have owned machines named: rozzzly-pc, rozzzly-mobile, rozzzly-work, rozzzly-tablet, and rozzzly-laptop. I like this convention, makes it easy to tell who the owner is, and which device it is.

Here's an example from a Modal component I wrote last week. It has a prop called "dismissOnEsc" which allows the consumer to decide if hitting the ESC key will dismiss the Modal. If (for whatever dumb reason) the consumer didn't want ESC to dismiss the Modal, but later on in the components life cycle decided that it should, well then nothing would happen because the event listener is registered in componentDidMount and the component wasn't remounted, it's props just changed. Here's the relevant snippet of code: componentWillReceiveProps(nextProps) { if (canUseDOM) { if (nextProps.dismissOnEsc && ! this .props.dismissOnEsc) { this .registerEscListener(); } else if (!nextProps.dismissOnEsc && this .props.dismissOnEsc) { this .unregisterEscListener(); } } } If you need me to explain further / show you the full code, just ask, I don't mind.