Consider using esri-loader?

[tomwayson]

I like how you've isolated use of the JSAPI to middleware.

It seems like that pattern would benefit from using esri-loader rather than treating esri modules as externals and then adding the JSAPI to the page via script tag and using it to load your bundle as an AMD module. Using esri-loader should improve initial load times (especially on mobile) and would allow users of this boilerplate to adapt it for isomorphic/universal (server-side) rendering techniques if their app calls for it. You can read more about those benefits and how it works here.

Would you be open to a pull request that switches over to using esri-loader?

[mvdbster]

Hi Tom. Let's have a chat about this next week perhaps?

I'm not 100% convinced that replacing one workaround with another workaround is a step forward (and I def. want to keep this repository as it is with the Dojo workaround). I think there should be a larger discussion about making the JS API a proper npm module.

[tomwayson]

I'd love to chat about this anytime.

I completely understand you wanting to keep this repository as is.

That said, I am so convinced that the esri-loader workaround is better than others that I just wrote a blog post that effect. But I might be a bit biased. 😄

I'll admit that in a map/scene-centric app like this boilerplate (i.e. no router and no routes w/o maps) the primary use case for esri-loader is to provide a better loading experience on mobile (although I'd guess it could probably help w/ this). However, I think that your idea of using the JSAPI as middleware is really good, and that people will want to use it in other contexts (like a react-router / redux app that only needs the JSAPI on the /signin or /map routes), but they'll find it won't work as is b/c they didn't start from this boilerplate. Then they'll have to figure out how this boilerplate works and try to get that configuration working in their app, or they'll have to convert to the code over to work w/ esri-loader.