Transloco v8 breaks ngx-transloco-markup

[Dafnik]

Hi, I'm a user of both, transloco and ngx-transloco-markup.

When trying to upgrade to transloco v8 I noticed that ngx-transloco-markup throws compiler errors. I already knew that transloco had some breaking changes and looked into the issue.

ngx-transloco-markup until now used HashMap and getPipeValue under the hood. Now both utilities are no longer exported (but still there as they are used by transloco itself).

(Jfyi, the removal of HashMap also isn't mentioned in the BREAKING CHANGES document)

Now I'm wondering if I should simply duplicate the functionality into ngx-transloco-markup or is there the possibility to re-export these utilities again from the @jsverse/transloco-utils package.

Please let me know if re-exporting the utilities would be OK from your side.

For reference https://github.com/dscheerens/ngx-transloco-markup/issues/25

[shaharkazaz]

Hey @Dafnik 👋 Thanks! I’ll update the BREAKING CHANGES doc.

Regarding exporting: @jsverse/transloco-utils is currently used for configuration loading, not really for Transloco tools. I’m not sure that’s the right place for it—but I agree the naming/structure could use some rethinking.

On the HashMap: I think it’s better if people don’t rely on it since it’s an internal type. In hindsight, exporting it under this name was probably a mistake—if it’s part of the Transloco API, it should be named accordingly.

As for getPipeValue: I honestly didn’t realize it depended on that. Copying the logic would mean manual syncing if the function changes in the future, which isn’t ideal.

I’ll give it some more thought—maybe exporting Transloco-related utils is the right call.

[Dafnik]

Thank you very much for your time & thoughtful response.

Regarding exporting: @jsverse/transloco-utils is currently used for configuration loading, not really for Transloco tools. I’m not sure that’s the right place for it—but I agree the naming/structure could use some rethinking.

Ahh, I see now. The folder I referred to was "coincidentally" named utils (where the utils I mentioned life) but has nothing to do with the @jsverse/transloco-utils package. Thanks for the clarification.

On the HashMap: I think it’s better if people don’t rely on it since it’s an internal type. In hindsight, exporting it under this name was probably a mistake—if it’s part of the Transloco API, it should be named accordingly.

Hm.. I mean in the end I can duplicate the functionality into the ngx-transloco-markup package. But as this is used quite often, something like this with a proper name for other libraries to consume would be great. But I also understand wanting to keep the API surface lean.

As for getPipeValue: I honestly didn’t realize it depended on that. Copying the logic would mean manual syncing if the function changes in the future, which isn’t ideal.

Yeah I agree, the function looks pretty stable to me. So exposing them for libraries would be great.

I’ll give it some more thought—maybe exporting Transloco-related utils is the right call.

Thanks again for your time, please let me know if I can help you with some of these things.

[Dafnik]

Hey! Sorry for pestering you about this issue.

Did you make a decision about this? As said earlier if you outline a path you would be fine with, I would gladly do the work to get this implemented.

Thanks again for your time

[shaharkazaz]

@Dafnik No worries — I’ve been tied up and wasn’t able to finish the task. I’ll expose the transloco-related utilities for now while keeping the HashMap internal. I’m considering adding a TranslocoParams type later, since I assume that’s where the HashMap was used.