Removed the public version of the -portal service

[cah-brian-gantzler]

Not sure you were aware you can do this, but it removes the public export of the service. You also could remove the - in the service name, since it is no truly private.

Note you could also remove the component exports as will and change the documentation to

<EmberStargate@Portal>

Also avoiding name conflicts.

I have been moving towards this as it clearly indicates the addon the component comes from and is a good start towards template imports.

Can do another PR if you would like to see the components working in your tests as well

[simonihmig]

Not sure you were aware you can do this, but it removes the public export of the service.

That's great. Tbh never have seen this before. Do you happen to have some link at hand where this is documented? Is this public API and guaranteed to stay?

[cah-brian-gantzler]

I can not find documentation for this. I had a discord discussion with Robert (rjwblue) about it and he confirmed this was public and was going to continue to be supported. I believe this may be part of they underlying that will make template imports work.
If you look at https://github.com/miguelcobain/ember-yeti-table we converted all the internal private components to use the template namespace

[simonihmig]

If you look at https://github.com/miguelcobain/ember-yeti-table we converted all the internal private components to use the template namespace

That's an excellent use case, and I would really like to use this pattern (e.g. ember-bootstrap has a lot of private (yielded) components). But tbh I would have expected this to be introduced in an RFC if it were really public, not? Also would like to know since which Ember version this is supposed to work (obviously it works in all those that this addon supports at least)...

@rwjblue mind chiming in and bring some light into this? 🙏 😀

[cah-brian-gantzler]

I dont remember the version, but it worked back way farther than I thought, was surprised. Yes I hope Robert sheds some light on when they may be documented since it has been working for a long time

[rwjblue]

Ya, it is a public API of ember-resolver (not Ember itself). When attempting to resolve something it parses the @ as meaning "this namespace" (remember back in the day when we had window.Foo style namespaces and you could refer to them, it is basically the same thing).

[rwjblue]

Its generally worked since at least 2016

[rwjblue]

These two tests are for that functionality:

https://github.com/ember-cli/ember-resolver/blob/master/tests/unit/resolvers/classic/basic-test.js#L117-L147

[rwjblue]

FWIW, the feature was added in ember-cli/ember-resolver#70 (2014).

[cah-brian-gantzler]

@rwjblue Thanks for all the clarification.

The other question was, is it documented? (Since its a little known feature) and should we be teaching this?

[rwjblue]

I dunno if it is documented, I'd be happy to land a PR adding docs to ember-resolver. To document more broadly we'd have to discuss a bit more (for example, over in the cli-guides repo).

IMHO, the main thing here is to ensure that service names are namespaced to avoid collisions, you can use this @ thing for that or you could make your services -ember-stargate-portal both (AFAICT) solve the problem.

[simonihmig]

Seems good to merge then!

Thanks @cah-briangantzler for the work, and @rwjblue for the insights! 🙏