feat(store): loaders

[rbalet]

Description

As we're now having multiple instance of the TranslateService, the only way to sync language across all services is through the store.

As this issue describe, when adding a new loader, and changing the lang, the parent loader isn't triggered anymore.

Cause

The loading happen inside the service, but this service is not aware of the other loaders

Proposed solution

Storing each loader inside the store, and calling it when needed.

• New loaders map inside the store class
• On service instantiation, add the new loader into the loaders map
• On service destroy, remove this loader (language aren't updated as this does not seems required)
• On language change, triggering every loaders.

Food for though

This PR is more "food for though" than a finite PR, as I'm aware following have not been solved

• Should we empty the translation on destroy? (I think we should not)
• Only the last compiler will be triggered, (we could also store compilers into a map and this would solve the error)
• This triggers one huge request, and we have to await it, maybe an other way could be optimized.

[CodeAndWeb]

getLoaders() should deliver an array of unique loaders.
we should hide the information that we use the indices. it's a implementation detail that does not need to be shared with the service.

using this:

provideTranslateService({
  loader: provideTranslateLoader(CustomLoader),
  compiler: provideTranslateCompiler(CustomCompiler)
})

  provideChildTranslateService({
    // no loader
  })

could add the same loader twice. this would lead to concurrent http requests for the same url.
this is why the list has to be unique.

[rbalet]

@CodeAndWeb I do not understand the following can you explain ?

we should hide the information that we use the indices

If you're talking about _loaderIndex, I though the service should be aware of it, as he's removing "himself" from the store on destroy

---

2. Same loader added twice.
   You're right, but I may be missing expertise here, do you now how to handle this possibility ?

I though about generating a random id per loader so I could check this loader, but it seems to be wrong.
But yet, we cannot get the instance ID in angular...

Doing so will force every use to add this value to theirs loaders.

But I do now understand why you wanted a counter, as it could be casted multiple time, you'd like to add, remove and delete it when it gets to 0.

Am I right ?

[CodeAndWeb]

currentLoader is not used anymore. remove it.
it would only confuse users.

[rbalet]

Yes, I'll do once I'm doing the testing

[CodeAndWeb]

... and finally, we need some tests for this functionality.

[rbalet]

const loaders = Array.from(this.store.loaders.value

Yes, I'll do the testing once we're done with the changes ;)

[rbalet]

@CodeAndWeb Thx for the help 😋

[rbalet]

@CodeAndWeb Can you notify me once an RC is released, that I can test it out on some projects?

Cheers