erlang and javascript interop

[vestal temple]

I'm trying to use gleam for my personal website and I had an idea to write the backend in erlang gleam and frontend using gleam with solid.js (with ssr probably manually implemented in erlang gleam as well).

The problem is I want to put both components in the same project which means there's going to be javascript specific gleam code (for purely client side interactions like event handlers), erlang+javascript gleam code (mainly for generating html), and erlang specific gleam code (for beam stuff).

I was wondering what's the best way to lay out the project for that purpose? The main issue is that it seems that gleam build goes through every file in the project for compilation which means that when the target is set to javascript then the erlang code would error out and vice versa. So is there a way to specify a set of entrypoints for gleam build?

Also let me know if there's any suggestions for this project since I'm really new to gleam. Overall the language feels really nice and I'm excited for the possibilities!

[topaz wolf]

Gleam isnt designed to work this way, instead you would have a monorepo with separate projects for your front and backend

[vestal temple]

Hmm I see. Although how is this implemented for lustre since it seems to implement javascript-based client side functionalities while also being mostly server-side?

And in terms of the monorepo it seems that the erlang + javascript ssr/csr code (which most likely need to import the javascript specific project) still needs to be treated carefully since it's being compiled by both targets. The best idea I can think of is to add erlang noop stubs for the client side javascript project which is a little bit annoying but not that big of a deal. Shared types between frontend and backend would be nice as well but I think that can be a separate project in the monorepo as well.

Would that be a good project layout then?

[topaz wolf]

gleam knows what functions in a dependency are called from your code, and so knows whether that code can be compiled for the requested project or not; projects dont get to choose what target they support it is determined by the package's api

lustre's surface api is 95% target-independent, and the parts that are target-specific will not compile if you try and use them in a project compiling to the wrong target

The best idea I can think of is to add erlang noop stubs
you do not need to do this

[topaz wolf]

project/
  server/
    ...
  client/
    ...
  shared/
    ...

[vestal temple]

the problem is there's going to be code that's evaluated by both erlang and javascript, like

// this will run once on the server to render a div, and it'll run again in javascript to hydrate the div and also register the handler
div("hi", onclick=this_will_only_run_in_js)

and that means the this_will_only_run_in_js would need to have a erlang stub in order for erlang to compile that piece of code

although if there's a way to tell gleam that the function passed in would never be called on the server then that would be nice, but I don't think that's possible