ReasonML with Phoenix?

I think its propose is similar to your implementation, Bucklescript-TEA.

I add that one to the Wikipedia page of Elm, by the way.

1 Like

6 posts were split to a new topic: What are Monads?

Another vote for the OCaml syntax

###Why I choose Bucklescript

by @tcoopman

The article is more on the “vs Elm” topic (in the most complementary fashion).

3 Likes

Verbosity aside - I think there is also a failure to communicate. In the C-family of languages “the stuff between braces” are statements. In Reason the braces have been repurposed for as “begin”/“end” tokens. But as a result of previous familiarity with the C-family of languages this way of using braces is going to delay viewing everything as an expression.

3 Likes

What I dislike about { .. } is that in a language like OCaml heavily relies on record it requires extra efforts to tell if it is a code block or a record. Rust has this problem as well.

2 Likes

Ditto, and it has been repurposed for objects as well (I think tuples are (/)?), so {/} is quad-purposed in ReasonML (maybe more), this is one thing I really dislike as it is forcing them to do weird things like {1, 2, 3} or {. 1, 2, 3} or {.. 1, 2, 3} or more and other weird things just to get things unambiguous again. OCaml’s syntax may look odd to javascripters, but it is chosen for a very good reason.

Links is tierless (like Ocsigen, or Ur/Web). You write code for the client, server and datastore in the same language.

Why didn’t you use the React OCaml library, like it is used here for instance ?

Because React has a few issues that I really don’t agree with, one is that it is substantially slower than mine, much heavier code to bring in (substantially larger), much longer startup time, and it’s not very functional (in the functional programming sense).

1 Like

Kind of let my “looking into React” slide but recently went back to some tutorials that I had lined up in my queue - but I have been doing them with ReasonReact instead.

I find Bucklescript/ReasonML really makes it obvious when React is being sloppy (sometimes things get ornery in a “I’m sorry Dave, I’m afraid I can’t do that” way.).

For one there’s no setState in ReasonReact - you have to use a reducerComponent with and reducer function that returns a ReasonReact.update type.

There is no Redux integration because it has it’s own Reductive library.

Personally, I don’t see the react-router bindings going anywhere. As far as I can tell react-router has a tendency to introduce deep coupling into components - in ReasonML it makes far more sense to capture the URI essentials in a variant at the top level and to convert it as required as it gets closer and closer to the leaf components.

And JSX seems even more loosey-goosey than usual - for the time being ReasonReact.element and ReasonReact.createDomElement make frequent appearances - to the point where you wish people would just realize that JSX isn’t markup but just source for a code generator (so can we just let go of the pretense).

So depending on how serious FB is about ReasonML, it may actually cause React to clean up it’s act (or at least lead to an alternate, cleaner interface for ReasonML).

Aside:

People are reading way too much into Presentational vs Container components divide. Almost regretting I wrote that.

Dan Abramov referring to Presentational and Container Components.

In a way this seems to be in line with Elm’s “no components” stance. Traditionally people expect components to combine the presentational and behavioural UI aspects. Container/Presentation splits the traditional “visual component” into two separate responsibilities.

I was talking about the OCaml FRP library here, not Facebook React. This TodoMVC example shows how it can be used to implement something close to what Elm gives you

Hmm, a few things I immediately notice, first it seems to be far more verbose (more like the old Elm <0.16 way, which used signals/frp instead of the event processing model that it and I use now), and it looks like loops could happen where mine prevents that by holding messages if one is already being processed. where with FRP that is significantly harder to do properly and user code can easily break it (this was a problem elm had in older versions as well).

Remember, Elm is not FRP.

yes I agree it is more verbose, React is a general purpose FRP library and there, they implement TodoMVC the way it would be done in Elm… but I thought it looked OK

As they implemented it, it looks very close to how it was done in Elm back in 0.16- versions, 0.17 had the overhaul that got rid of FRP.

1 Like

Does anyone have an up to date version of how to use bucklescript with Phoenix and brunch? I’m running into some issues that I can only assume are unique to brunch.

In particular, if I set the module output to es6-global it seems to find all modules in node_modules correctly, but then brunch complains that imports cannot be done outside of a top level context (from bs-webapi). If I use the commonjs modules I get complaints about bs-platform not being available on page load. Any solid resources on how to use bucklescript with phoenix and brunch?

P.S: I likely won’t be able to change the JS build system on this project, so I kind of need it to work out with brunch even though I’d rather switch to something else.

Don’t use brunch for that part, just use bucklescript’s own watcher added to the phoenix definition (you can have multiple watchers listed), and have brunch just watch the output javascript directory (make sure to have brunch’s npm integration enabled in the config, it ‘should’ be by default), easy-peasy then. :slight_smile:

Ok, just to sort of expand on the scenario:

I want to use brunch just as we have previously, but I want to import code written in OCaml/Reason for use in the compiled brunch files.

What is happening currently, even though things seem to be compiling fine (I run bsb on the side and compile those file into the bundle currently) is that I get this runtime error:

Error: Cannot find module 'bs-platform/lib/js/curry.js' from 'bs-webapi/src/dom/nodes/ElementRe.js'  requestWait.js:61:11

Which suggests this way of simply compiling the files on the side and including them as just another JS file is not working.

It was told to me that this would be helped by the global module type in bs (es6-global is one such way and it will according to the bucklescript channel on discord check properly in node_modules). I don’t particularly care to have brunch deal with everything, I really only need this to work alongside it and currently it doesn’t seem to be happening.

This just means that brunch cannot find the npm files, don’t think this is a bucklescript/reason issue at all. Are you able to import other npm files via an ES6 javascript file directly? That’d definitely be the first thing I’d test.

I suppose it is possible that if BuckleScript is globally installed Brunch may not be able to find the packages.

Maybe npm link bs-platform etc.? If Brunch follows links …

Absolutely do not use globally installed packages with brunch. In fact never use globally installed bucklescript at all as it’s API has a tendency to break from version to version and thus a project that ‘was’ working suddenly does not work. You should put all NPM dependencies for a project (including bucklescript) as a devDependency in the packages.json file for NPM. Anyone that says that bucklescript can safely be installed globally (including the author, I really don’t know where he gets the idea that this is safe, as you can plainly see with such an issue) should be ignored.

This is one of the reasons that I’m leaning back to the, though more unreadable output, but actually and properly consistent js_of_ocaml over bucklescript. The gain in readability from bucklescript is not worth the breakages it keeps doing, especially it’s DSEL attributes it keeps adding all over the place.

Better yet I want webassembly to become in higher use now, that is the end-game way to go, and bucklescript won’t work there as it is, but js_of_ocaml (via normal ocaml) will.