feat(store-devtools): export private Redux Devtools Extension injection token

[edusperoni]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https:/ngrx/platform/blob/master/CONTRIBUTING.md#commit
• Tests for the changes have been added (for bug fixes / features)
• Documentation has been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, local variables)
[x] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

What is the current behavior?

REDUX_DEVTOOLS_EXTENSION is private and we're unable to provide a custom interface implementation in platforms where window is not defined.

What is the new behavior?

We export REDUX_DEVTOOLS_EXTENSION as ɵREDUX_DEVTOOLS_EXTENSION allowing for custom implementations of the extension interface

Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information

This change is needed to be able to debug ngrx using remote devtools under a @nativescript/angular application.

[netlify]

✔️ Deploy Preview for ngrx-io canceled.
Built without sensitive environment variables

🔨 Explore the source changes: f36d865

🔍 Inspect the deploy log: https://app.netlify.com/sites/ngrx-io/deploys/6227a8e2c613de0007ccb610

[brandonroberts]

Thanks @edusperoni. I don't see a reason why we need the symbol in front of the export if it's going to be part of the public API at this point.

[timdeschryver]

Could you also provide some more context about the use case and what you would do on your end? I'm asking because this could also become a part of the NgRx project or it could be added to the docs.

[edusperoni]

Thanks for taking a look at this! I thought about adding the symbol so it would be easier to make it an exported private API, which means it could break at any point without notice in case of refactoring or changes in the devtools protocol, but I can remove the symbol no problem.

In my case, I'm writing a plugin for NativeScript that will allow us to use remote devtools with NgRx directly on the phone. Since we don't have a window object, the currect way of grabbing the extension won't work, so I'm creating a module that provides that token and implements all the required functions from the extension and uses native websockets to communicate with the computer running remote devtools.

In sum, this allows us to be more flexible when dealing with the devtools extension. Other frameworks may also benefit. Ionic seems to have a window object, so it's less of a problem (https://medium.com/nextfaze/remote-debugging-ngrx-store-with-ionic-74e367316193). And the reason we can't just introduce the window object in NativeScript is because many libraries check for a window object to detect if they're running on a browser or not, so it could have unintended side-effects.

[brandonroberts]

Thanks @edusperoni! If you have a blog post or guide to link to for setting up the remote devtools feel free to share it

[edusperoni]

@brandonroberts I'll have more to share in the coming weeks in terms of blog posts, but If you want to take a peek, I'm developing the plugin here https:/valor-software/nativescript-plugins/tree/feat/nativescript-ngrx-devtools/packages/nativescript-ngrx-devtools and it should be released soon.

[edusperoni]

Hey guys! Sorry, I forgot to post the blog link here once it was published.

If you want to read more about how we're using it in NativeScript with our own custom "extension", here's the blog post: https://valor-software.com/blog/Debugging_NgRx_in_NativeScript_with_Redux_DevTools