True, and admittedly I've only cast a cursory glance over Relay to keep track of where it is every now and again so maybe its unfair of me to write it off quite so quickly. But I think you're also right about the learning curve being made artificially steep by the poor docs, and when you're introducing this stuff to a team who are already new to GraphQL, adding another framework on top with even poorer docs than Apollo is a hard sell
I do on the whole yes, its not something I rave about unreservedly the same way I do about styled-components for example, but its still a tool I'd opt for on projects that actually have a need to do GQL stuff.
Its like your favorite screwdriver that you somehow always manage to cut yourself on - you're extremely grateful that you have this tool, it lets you tighten screws even in the narrowest spots, you just wish the handle wasn't so damn sharp
I'm doing a big Apollo/GraphQL piece for the BBC for a lot of the same reasons OP lists, and have run into pretty much all the same issues with Apollo that OP has.
Its rough because Apollo does so much for you, its wonderful, but there are so many sharp edges and pitfalls - from the buggy devtools to the lack of/incorrect docs, major unanswered github issues & constant API breaking changes even on patch/minor version bumps, its been an uphill struggle all the way. All that said, it still seems like the best tool for the job, Relay still has a huge learning curve & has already had two major branches with no refactor path between (Classic/Modern) & the numerous other implementations all lack things Apollo gives you for free.
If your usecase is simple, using Apollo to query a GQL server with a well defined schema doing little to no client state handling it can be pretty straightforward, but the complexity ramps up crazy quick as soon as you start messing around with caches or persistence or local state.
The Apollo folks seem to have a handle on things but hopefully I/we can start contributing back, if not with feature work than with documentation
This is true, but I've found it far more common that a predecessor at the company I'm at wrote the code and isn't around to support it anymore.
For simple components it's no biggie, but for non-trivial components it can take about the same time to debug as an external module, the benefit of the external module generally being better documentation, although thats not a given.
I was just thinking "Huh, I used to work with someone who went to work for Massive" until I realized you were the same someone :) Interesting to hear how the Massive/Ubi editorial relationship works from the inside
I think you're right about a general move towards a Git monoculture (as opposed to a GitHub one), but there are dozens of great Git repo hosting/collaboration companies - GitLab, Bitbucket & SourceForge to name a few of the bigger ones
As someone coming from a traditional strict separation-of-content-and-style background and now convert to Styled Components, CSS-in-JS felt unnatural to me when I first encountered it. The problems with styles in large applications are well known and I had a solid handle on them with BEM and other bits of tooling, namespacing styles to a particular React component to avoid collisions etc.
It took me helping my brother learn how to do web development to shake me out of that mindset. He's not from a traditional webdev background and he got quite far quite fast with React. When he showed me his code, I noticed he was inlining all of his styles in his relatively small React components. I was going to explain why its bad practice to do that, but when you're building small almost atomic components, that approach actually makes a lot of sense, its what the BEM methodology tries to do albeit in a poorer way. CSS-in-JS tools like Styled Components preserve the spirit of this approach and minimise the downsides.
I think CSS-in-JS lends itself quite nicely to atomic design. At my current company, one of the first things we did was build a component library of atoms & molecules that are shared across many applications, keeping our design language very consistent.
We also make heavy use of Styled Components' theming capabilities, so we wrap our React apps with a ThemeProvider and give it an object with theme variables that drive the look and feel of our components. This is super useful when you have to support whitelabeling like we do, but even if you don't, its nice to keep your mystery-meat colors and spacings all in one place similar to how you might with SASS.
One of the gripes a lot of people have with CSS-in-JS is portability, and while that is a drawback, I feel it's an anti-pattern to rely on shared CSS styles to enforce design consistency across many deployables. It's kind of a classic case of developers trying to solve a process issue with technology, which is admirable, but from experience styles go out-of-sync with eachother quite easily and its rare that you can drop a CSS file into another project and have styles just work without having to do rework, so the benefits of sharing CSS rather than writing new styles off a styleguide are marginal at best. Again, this is all my subjective experience, your mileage may vary.
We still have a couple of issues with Styled Components, no technology is perfect and SC is still relatively young, but so far the pros have far outweighed the cons to the point where none of us really feel the itch to go back to SASS or plain CSS. I'm definitively not a magpie developer by any stretch, I'm usually resistant to change for the sake of change, but CSS-in-JS makes a lot of sense when you use it how its intended