#Best Practice for JavaScript Target specific logic

1 messages · Page 1 of 1 (latest)

grave citrus
#

I am working on a UI Components library for Lustre and support both targets. For browser specific functionality it gets a bit awkward, since for a toast.info function we can f.e. dispatch an event when we are in a lustre application running in the browser. But if we are rendering the html on the server we would have a different function (maybe toast.onclick_attr_info() or something more accurately named) that would produce a string containing some javascript that we can attach to a attribute("onclick", ...) on some element.

You could alternatively make the same function dispatch the toast in the browser on the javascript target and return the javascript eval string on the erlang target, but that sounds like recipe of confusion for developers and fullstack lustre applications where client and server components might be mixed.

So my questions boils down to wether you should make use of @target(javascript) or rather provide an empty implementation for the erlang target where you would just return Nil.

I am aware that Gleam discourages @target(javascript) and you should only use if there is absolutely no way around it. So is an empty implementation with proper documentation encouraged in my specific use case?

spring nexus
#

You should not make use of deprecated features, no.

#

It is not discouraged, it is fully deprecated and will not work in future.

grave citrus
#

Oh I didnt know its fully deprecated noted

edgy locust
#

it's also somewhat bad practice to use on* attributes - use custom elements instead!