Static pages are always stateless components (functional or PureComponent).
Any custom CSS that isn't a part of the site's overarching CSS system is kept in the component itself (with CSS in JS), inline styles (since it's static anyway and often cached), or in a separate CSS file. Depending on the project's CSS setup, I'd have a assets/css/static/ that contains each component's modular CSS.
Doesn't really matter.
The component ecosystem is so large, that I often get multiple <TextBox /> imports in a single file, which thanks to ES6 are renamed (import { TextBox as MUITextBox } from 'material-ui').
Context API for simple state, like "Is the user logged in?". I reach for Redux/RxJS when the Context API is limiting, like when you need state management for SSR or complex and/or asynchronous component interactions.
Stateful when you need, stateless when you don't. It's that simple.
It's better practice to just start stateless and add state when you start reaching for it. Eventually you'll find you can plan for these things when architecting future apps.
Nope. You can use your own custom store (a store.js file that gets imported across the app), any other library, pass props around, use the Context API, whatever solutions works for you and the complexity of your state.
Usually yes, but it can depend.
Having a complex "machine" where me turning one part effects others. Context API and prop drilling work fine, until you have 50 things to manage in your state - or the components don't align in the tree as children.
Local storage works great for client side, but doesn't work server side. Context API works fine for simple cases like only tracking user authentication in an app, or more localized state. So you end up using Redux and serializing the Redux object for the server side to access as well.
You could use multiple context APIs to keep track of things like user auth and app-wide alerts. Or you could just dispatch one action with Redux, and dispatch two (or more events) in one, in the same function.