Circular Import Best Practice? about swapi-graphql HOT 3 CLOSED

@joefraley, I'm personally curious, is their any particular reason why these sort of imports are considered bad practice?

from swapi-graphql.

@AGS- basically its an open question how they should work or what to expect from them. but it does look like the thunk method of calling code used in this SWAPI example's resolvers circumvents the issue.

for concerns, see:
http://eloquentjavascript.net/10_modules.html#h_E/zWqBFdy8
https://stackoverflow.com/questions/30378226/circular-imports-with-webpack-returning-empty-object#answer-30390378

but interesting discussion here: https://medium.com/content-uneditable/circular-dependencies-in-javascript-a-k-a-coding-is-not-a-rock-paper-scissors-game-9c2a9eccd4bc#354f

from swapi-graphql.

@joefraley - I personally have no strong opinion on the matter. I've seen many coding patterns with circular dependencies that had a negative impact on the code/library quality, and formed a generally negative opinion towards it, but I agree with you that it should be more about what the intention of having a circular dependency is.

I think the medium article that you included explains the case with swapi-graphql very well. We could definitely include all types into one file and remove the need for the circular dependency, but I believe that having different files for each type, although with the circular dependency, allows for a better readability/understanding of each type.

Just fwiw, This block suggests that the need for requiring these modules is to construct the connection types.

from swapi-graphql.