#Is it possible to create top-level bindings?

1 messages · Page 1 of 1 (latest)

twilit jasper
#

Gleam has constants, but their made for actual constants. I'm looking for a way of binding a non-constant non-mutable global. For example, in React, you need a stable function or object reference:

fn my_context() -> ReactContext MyContext {
  create_context(todo)
}

The above signature, although does what you think, doesn't work, because every time the function is called, it will yield a new context object with a diferent pointer. I.e., it's not referentially transparent.

How can I go about doing something like the following, but have actually compile?

const my_actual_context = my_context()
placid arch
#

In react this is why useMemo exists

ornate elm
#

You would pass it in from further up in your program

twilit jasper
#

Right, but that's the point of using context, to not pass it down via prrops

#

So I'm guessing it's not really possible outside of FFI

#

With FFI, I can do:

const myContext = createContext(blah);

export const my_context = () => myContext

and then access it from gleam. I was just hoping of another way 😦

#

Also, sorry in case I dind't provide context (no pun intended) of what context means here.

When I say context, I'm referring to React's implementation of context, which is a way to access shared state from above in a component tree without needing to pass the value through each and every level of a component tree

placid arch
#

Gleam is an immutable functional programming language, you cant escape that fact

#

React context is just react automatically drilling props for you, in gleam we specifically do not encourage these kinds of apis (even where they’re possible) and great care is taken to keep things explicit

ornate elm
#

Trying to make Gleam non-functional isn’t going to result in a good experience. You need to either embrace the different programming style or use something else really

#

Tools work best when you use them for what they are good at

twilit jasper
#

Fair enough, I'll take your advice!

I'll go back to lustre now lol

I wanted to try and get react going here, rather than lustre, because with TEA, I almost always end up with a component tree anyways, because my models are marked opaque. And in lustre, you need to update state explicitly when "props" change, which you do not need to do in react.

placid arch
#

Lustre has components