I'm not really sure what's soured your opinion of Gatsby so severely, but I've had quite the opposite experience to you building and shipping multiple production Gatsby and Next code bases. In my mind, Gatsby's what I reach for by default, but if I know I'll have custom use cases or need more backend functionality then Next is my choice. Also, with Next's recent addition of serverless-rendering (nextjs.org/blog/next-8/#serverless...) it will likely fit in a lot better to my existing serverless applications.
Here's the test output I see for the redux directory in that particular package:
❯ yarn jest packages/gatsby/src/redux
yarn run v1.12.3
$ jest packages/gatsby/src/redux
PASS packages/gatsby/src/redux/reducers/__tests__/page-data-dependencies.js
add page data dependency
✓ lets you add a node dependency (13ms)
✓ lets you add a node dependency to multiple paths (1ms)
✓ lets you add a connection dependency
✓ removes duplicate paths (1ms)
✓ lets you add both a node and connection in one action (5ms)
PASS packages/gatsby/src/redux/reducers/__tests__/config.js
config reducer
✓ let's you add a config (19ms)
✓ handles empty configs (2ms)
✓ Validates configs with unsupported options (41ms)
✓ It corrects pathPrefixes without a forward slash at beginning (2ms)
✓ It removes trailing forward slash (1ms)
✓ It removes pathPrefixes that are a single forward slash (1ms)
✓ It sets the pathPrefix to an empty string if it's not set (1ms)
console.log packages/gatsby/src/redux/reducers/config.js:16
The site's gatsby-config.js failed validation
console.log packages/gatsby/src/redux/reducers/config.js:19
ValidationError: "someRandomThing" is not allowed
PASS packages/gatsby/src/redux/reducers/__tests__/redirects.js
redirects
✓ lets you redirect to an internal url (5ms)
✓ lets you redirect to an external url (1ms)
✓ lets you redirect using https (1ms)
✓ lets you redirect using http (1ms)
✓ lets you redirect using // (1ms)
✓ lets you redirect using ftp (1ms)
✓ lets you redirect using mailto (1ms)
PASS packages/gatsby/src/redux/__tests__/status.js
Status actions/reducer
✓ allows setting plugin status (4ms)
✓ allows updating status (2ms)
✓ throws an error if status isn't an object (1ms)
✓ throws an error if the plugin name isn't set (1ms)
PASS packages/gatsby/src/redux/__tests__/jobs.js
Job actions/reducer
✓ allows creating jobs (7ms)
✓ allows completing jobs (4ms)
✓ allows updating jobs (1ms)
✓ Allows you to set other info on the job
✓ throws an error if an ID isn't provided (1ms)
✓ throws an error if endJob is called for a job that's already ended (2ms)
PASS packages/gatsby/src/redux/__tests__/pages.js
Add pages
✓ allows you to add pages (11ms)
✓ Fails if path is missing
✓ Fails if component path is missing (1ms)
✓ Fails if the component path isn't absolute
✓ Fails if use a reserved field in the context object (1ms)
✓ adds an initial forward slash if the user doesn't (2ms)
✓ allows you to add pages with context (1ms)
✓ allows you to add pages with matchPath (5ms)
✓ allows you to add multiple pages (2ms)
✓ allows you to update existing pages (based on path)
✓ allows you to delete paths (1ms)
PASS packages/gatsby/src/redux/__tests__/run-sift.js
run-sift
✓ resolves fields before querying (1ms)
filters by just id correctly
✓ eq operator (20ms)
✓ eq operator honors type (1ms)
✓ non-eq operator (1ms)
PASS packages/gatsby/src/redux/__tests__/babelrc.js
Babelrc actions/reducer
✓ allows adding a new plugin (7ms)
✓ allows updating the options of an existing plugin (2ms)
✓ allows adding a new preset (1ms)
✓ allows updating the options of an existing preset (1ms)
✓ allows specifying the stage for the plugin
✓ allows specifying the stage for the preset (1ms)
✓ sets default presets/plugins if there's no userland babelrc (1ms)
✓ allows setting options
✓ allows setting options on a particular stage
✓ allows merging config items (1ms)
PASS packages/gatsby/src/redux/__tests__/nodes.js
Create and update nodes
✓ allows creating nodes (14ms)
✓ allows updating nodes (2ms)
✓ nodes that are added are also "touched" (1ms)
✓ allows adding fields to nodes (1ms)
✓ throws error if a field is updated by a plugin not its owner (1ms)
✓ throws error if a node is created by a plugin not its owner (1ms)
✓ throws error if a node sets a value on "fields" (1ms)
Test Suites: 9 passed, 9 total
Tests: 61 passed, 61 total
Snapshots: 35 passed, 35 total
Time: 5.92s
Ran all test suites matching /packages\/gatsby\/src\/redux/i.
✨ Done in 7.51s.
I've never heard of documentation that was too beginner friendly, but if you want some more complex or involved documentation from Gatsby, check out some of their "behind the scenes" docs that explain the architecture decisions in Gatsby:
Gatsby also hosted a webinar recently that detailed a lot of the technical features included out of the box with Gatsby: gatsbyjs.com/behind-the-scenes/
I'm not really sure what's soured your opinion of Gatsby so severely, but I've had quite the opposite experience to you building and shipping multiple production Gatsby and Next code bases. In my mind, Gatsby's what I reach for by default, but if I know I'll have custom use cases or need more backend functionality then Next is my choice. Also, with Next's recent addition of serverless-rendering (nextjs.org/blog/next-8/#serverless...) it will likely fit in a lot better to my existing serverless applications.
You've missed some tests for Gatsby's Redux actions/reducers here: github.com/gatsbyjs/gatsby/tree/ma...
Here's the test output I see for the
redux
directory in that particular package:I've never heard of documentation that was too beginner friendly, but if you want some more complex or involved documentation from Gatsby, check out some of their "behind the scenes" docs that explain the architecture decisions in Gatsby:
Gatsby also hosted a webinar recently that detailed a lot of the technical features included out of the box with Gatsby: gatsbyjs.com/behind-the-scenes/
You wonderful patient man lol