Hey! :wave: Is there any strategy to use moko reso...

# moko

[Nacho Ruiz Martin]

Hey! 👋
Is there any strategy to use moko resources from JS code using @JsExport?

[Nacho Ruiz Martin]

@alex009 Do you reckon it’d make sense to add some parameter in the Gradle plugin to mark the generated resources in JS with @JsExport?
StringResource class and other similar ones would also need to be marked with @JsExport.
That or new classes are generated wrapping those if the gradle plugin is marked with the parameter.
A manual sample of this would be:

[alex009]

hi! i not use JSExport yet, so i have questions 🙂

can we add this annotation by default or with it will be some perfomance/bundle size degradation?
why annotation should be on StringResource and other container classes?

[Nacho Ruiz Martin]

It does come with a size increase when targeting KJS, yes.
The idea is to be able to use those classes from JS, that's why. A potential user of the KMM library from JS would want to get a string and call localized from JS, for example.

[alex009]

add @JSExport to generated code - possible, with some gradle plugin parameter. but runtime classes like StringResource will be always with @JSExport. it will be ok for projects where not use this feature?

[Nacho Ruiz Martin]

The only downside I am aware of is the size increase on the JS generated package: https://kotlinlang.slack.com/archives/C0B8L3U69/p1703682488880949
Otherwise, what could be done is to generate wrappers marked with @JsExport usable from JS only if the gradle plugin parameter is present.
Or, and I think this makes more sense, to create a wrappers package that people can include optionally. This solution was discussed for Decompose library here. https://kotlinlang.slack.com/archives/C03H3N51SKT/p1703676062908999?thread_ts=1702059044.603499&cid=C03H3N51SKT

Let me know if anything works for you and if you need/want me to contribute.

[alex009]

at now please create issue with this feature request. and after 0.24.0 release you can send PR with this feature.
While 0.24.0 not released no sense to change gradle plugin - in 0.24 plugin rewritten

[Nacho Ruiz Martin]

Sure thing! Maybe transitive exports will be ready for then and this won't be needed anymore.