Closed Kingdutch closed 2 years ago
I wonder if we can do anything sensible to avoid the issues with exposing internal code...
I think the difficulty for me at the moment is that I'm not entirely sure what is and what isn't internal code.
For example some of the bindings may be useful, though I can also see how you'd expect projects to define the bindings themselves so that RelayRouter can freely change them.
I think anything exported from RelayRouter
should be considered part of the public API. Perhaps with an exception of RelayRouter.GeneratorTooling
or something which could be used in __generated__
code. Though that would give a clear namespace to say "Your code may break if you use that, because we will change it and regenerate calling code automatically"
Yes, I like that. Maybe we could put it in an Internal
namespace? I know there's something similar already, but maybe it can be worked around.
This renames the modules in Relay Router to all be internal. The only module that's kept is
RelayRouter
which exposes only those things that are considered to be part of the API.In this commit we focus on getting this set-up working. It also reveals that more than the public API (e.g. Bindings and Internal) are actually exposed because they're required by generated code.
We may want to move things that are needed in the generator to something like RelayRouter.GeneratorHelper.* so it's clear for user code that things like Bindings and Internal are not actually part of the API.
Fixes #11