Flame: A PureScript front-end framework inspired by the Elm architecture

https://github.com/easafe/purescript-flame

by vyuh • 5 years ago

156 39 5 years ago

sfvisser2• 5 years ago

Nice, looks very clean.

As in Elm, I’ve never fully understood why the events emit a value of some message type that gets interpreted into a function from ‘state -> state’ instead of handling with a state transformation directly.

Feels like boilerplate to me. I can see situations where this approach is useful, but should it be the default?

I guess you can always change your message type to ‘a -> a’ and interpret with ‘id’ if you want to.

pdamoc• 5 years ago

I’ve never fully understood why the events emit a value of some message type

In Elm, the Model can be updated faster than the DOM. In other words, the view is rendered at the speed of requestAnimationFrame but the model can change in between animation frames. This means that if you handle model changes inside the view you might get out of sync with the model.

Here is a program [1] that shows this problem. If you click "SnapShot" you will sometimes get the same number but sometimes get different numbers.

[1] https://ellie-app.com/dmddFd9whtYa1

k_bx2• 5 years ago

Events are always serializeable, inspectable, and can be rewinded backward/forward in Elm. It is indeed producing a lot of boilerplate from my experience, but there is a certain complexity guarantee that comes with it in terms of keeping things simple that I, personally, enjoy.

sfvisser2• 5 years ago

Yeah, so the trade-off is you get some stuff for free that you might not need. Paying with some boilerplate. Fine design choice obviously.

Writing a lot of react (without redux) I never really miss serializeability and it’s easy to bolt on locally if you need it.

_0w8t• 5 years ago

The whole state is immune so it is not possible to handle state change locally in a sub-component. The parent component that embeds it needs to call it and place a new updated component state into a new whole state. But then the parent needs to know which events go into the component. The messages nicely allow for that.

Besides already mentioned ability to serialize messages it also allows to preprocess or filter messages in the parent.

agumonkey• 5 years ago

Impressive metrics https://flame.asafe.dev/benchmarks

eyelidlessness• 5 years ago

I look forward to seeing this in the Solid benchmark suite.

vyuh4• 5 years ago

Elm handicaps my attempts of "making impossible states impossible" because:

- I can't have Sets of arbitrary Types they must be `comparable`. I cannot create a custom comparable type.

- Records, Bool and custom Union Types are not `comparable`

- Bool and Simple Union Types could have been comparable if their comparison worked like they were Enumerated Types. Elm does not have Enumerated types.

Basically https://github.com/elm/compiler/issues/1008 made me look for better alternatives.

mrweasel• 5 years ago

Did you find better alternatives? I'm currently trying to learn a bit of Elm. So far it's basically the only "Javascript framework" that I've been able to get up and running, while still understanding how things actually work.

cies5• 5 years ago

This post links to a PureScript project that is probably the easiest PS framework around.

ReScript + rescript-react is a good alternative. Less safe, waaaay more verbose; but backed by Facebook.

This is quite cute (in TypeScript though): https://github.com/cyclejs/cyclejs

And Yew is super cool, it goes the WASM route (in Rust): https://github.com/yewstack/yew

pharmakom• 5 years ago

There is a library for Elm style apps in F# called Elmish. Unlike Elm, F# compiled with Fabel can call JS directly (and vice versa).

vyuh4• 5 years ago

I am hopeful about using Flame (posted link) along with https://pursuit.purescript.org/packages/purescript-ordered-c....

Looks like purescript development requires node, purescipt compiler, and spago build tool. I have set these up. In future I'll try to learn Flame framework and then adapt my elm code to this.

samhh• 5 years ago

PureScript's build system is very good (Spago), and the language is too, but it is tougher to learn than Elm veering much nearer Haskell.

mvolfik• 5 years ago

I'm also this kind of i-want-to-know-how-things-work person and also never managed to stay at learning React, Vue etc. But a few months ago, I discovered Svelte and I absolutely love it. I recommend you to give a shot to their excellent tutorial which you can finish in < 1 hour https://svelte.dev/tutorial/

cies5• 5 years ago

Elm is a walled garden (as advertised). Agreed this is annoying (for me coming from Haskell). But it does have a great learning experience for those new to FP.

All trade offs.

vyuh4• 5 years ago

Can you (or anyone) point me to the files where this `comparable` logic is implemented in elm compiler? I'll try my hand at least making Bool and Record types Comparable. Or maybe implement comparable Enumerated Type in elm which behaves mostly like custom Union Type.

dwhitney3• 5 years ago

FWIW this post is about PureScript, not Elm. The library is an implementation of the Elm Architecture in PureScript. Elm is a language. The framework that goes along with it is called "The Elm Architecture". The Architecture can be implemented in any language. Here's an implementation in TypeScript: https://github.com/gcanti/elm-ts

dwhitney3• 5 years ago

Also PureScript addresses all of the issues you've complained about above :)

throwamon• 5 years ago

You replied to OP, so I suppose they know.

pjmlp• 5 years ago

Amazed to see PureScript is still around, I guess.

It was everywhere on conferences like 5 years ago.

emptyparadise• 5 years ago

Misread that as "PostScript" and was confused but curious.

haskman4• 5 years ago

Purescript-Concur is simpler, and allows you to use elm-architecture as well, but also allows you to use your existing functional programming toolkit to the fullest. It also has react bindings - https://github.com/purescript-concur/purescript-concur-react.

Here's what a counter example looks like -

    counter count = do
      button [onClick] [text (show count)]
      counter (count + 1)

Check out a comparison with elm-architecture at https://ajnsit.github.io/concur-documentation/ch03-01-replic....

dorian-graph• 5 years ago

That Elm comparison is so nice. I felt like half the time I was writing Elm, it was spent on the manual work of the things described in there.

haskman4• 5 years ago

Thank you! All the manual wiring in Elm can be very frustrating!

Also not having to expose all the action datatypes when they are only being used in a single place can really improve code structure.

DylanSp• 5 years ago

Two questions that I didn't see answered in the docs:

- How do I manage state that isn't local to one widget? A counter's nice and local, but I don't see how application-wide state gets handled.

- How are data fetching and other asynchronous actions wired in?

dwhitney3• 5 years ago

I was wondering that myself. Here's an Ajax example: https://github.com/purescript-concur/purescript-concur-react...

It could use some type signatures, but it makes sense.

As for managing state, my understanding of the Elm Architecture is that there is one "global" state data structure, and various parts of it are handed down from parent to child. So my question would be the opposite of yours: what if I want local state? Is that possible? There are situations where some toggle being on or off isn't very important and keeping track of it in a global data structure is burdensome

haskman4• 5 years ago

1. Application wide state is easy since you can always access state from parent components in child components. The problem occurs when you want to update parent state from child components.

Fortunately, you can make your own abstractions in Concur. For example, you can use a "Wire" - which lets multiple child components share and update parts of the parent's state (https://github.com/purescript-concur/purescript-concur-core/...). Note how this abstraction just uses the high level Concur API, and doesn't depend on the UI backend. With a wire the code might look something like this -

  -- A wire into parent's state, accessible using `with`, and updateable using `wire.send`
  counter wire = with wire \i -> do
    button [onClick] [text (show i)]
    wire.send (i+1)

And you can compose several counters that share state like this (the first two counters will increment together -

  -- Parent component creates a wire using `local` and an initial value
  local 0 \w -> div []
    [ counter w
    , counter w
    , some
    , other
    , widgets
    ]
  -- Beyond this point the local state is gone and can't be accessed
  doSomethingElse

2. Concur widgets can perform sync effect as well as async effects using `liftEffect` and `liftAffect`, and the results of those actions are available within the monad just like other widget results. Does that answer your question?

wagslane• 5 years ago

I'm really happy to see more PureScript support! I recently built a playground for purs in the browser: https://app.qvault.io/playground/purs

Flame: A PureScript front-end framework inspired by the Elm architecture

Related Stories