To do this, I need to instantiate a subclass of my "root" application class which would live inside the gatsby project itself. If I made a gatsby plugin as an npm package, I'd need some way to inform the plugin where it can find that root subclass from the current gatsby project. Something like:
Root subclass is found at: src/Protoculture.ts
[the configuration feature desired] imports and holds a reference to the root subclass constructor
My gatsby-browser.tsx somehow receives and inspects this config
My gatsby-browser.tsx instantiates the root application in onClientEntry, which kicks off into my DI ecosystem allowing me to resolve out things like redux and other goodies
( Cheap plug: @KyleAMathews - feel free to look at protoculture for inspiration as it's all about application structure. It might offer you some ideas for things like https://github.com/gatsbyjs/gatsby/issues/858 . FWIW, protoculture is inspired by the laravel web framework and countless other DI systems. )
One particular plugin I have in mind is to integrate with my application framework ( https://github.com/atrauzzi/protoculture ).
To do this, I need to instantiate a subclass of my "root" application class which would live inside the gatsby project itself. If I made a gatsby plugin as an npm package, I'd need some way to inform the plugin where it can find that root subclass from the current gatsby project. Something like:
src/Protoculture.ts
gatsby-browser.tsx
somehow receives and inspects this configgatsby-browser.tsx
instantiates the root application inonClientEntry
, which kicks off into my DI ecosystem allowing me to resolve out things like redux and other goodies( Cheap plug: @KyleAMathews - feel free to look at protoculture for inspiration as it's all about application structure. It might offer you some ideas for things like https://github.com/gatsbyjs/gatsby/issues/858 . FWIW, protoculture is inspired by the laravel web framework and countless other DI systems. )