Open j-hotlink opened 5 years ago
I'm not the author of this but I am of bucklescript-tea.
I'm uncertain if/how the injection of JSX into Vdom.t nodes affects the purity of tea - can you give some pointers on this?
Nope, views are immutable, they should be fine, it's just a mapper from the JSX PPX output to the view calls instead.
Do you forsee any significant issues getting your library to work with ocaml syntax (which I use) rather than reason?
I wouldn't see any issues, but I've not tried yet. From my understanding the JSX PPX works fine in OCaml (since reasonml compiles to ocaml, it would have to, you can use refmt to convert reason to ocaml to see how it works).
I'm receiveing the error(s) below when trying to install (into a docker container). I'm new to bucklescript (& npm) - do you have any advice on how to resolve?
Can you post your package.json file as well? And do you have a sample github project that we can clone and try running?
I'm not the author of this but I am of bucklescript-tea.
Thanks for the reply, and the really cool library! Been using it for less than a week but already much happier than I was with Elm.
I'm uncertain if/how the injection of JSX into Vdom.t nodes affects the purity of tea - can you give some pointers on this?
Nope, views are immutable, they should be fine, it's just a mapper from the JSX PPX output to the view calls instead.
I'm not sure I understand - are you saying JSX views are immutable? I thought JSX functions could respond to browser events and directly change the browser dom outside of the elm update cycle - creating a problem... or is that incorrect?
Do you forsee any significant issues getting your library to work with ocaml syntax (which I use) rather than reason?
I wouldn't see any issues, but I've not tried yet. From my understanding the JSX PPX works fine in OCaml (since reasonml compiles to ocaml, it would have to, you can use refmt to convert reason to ocaml to see how it works).
Thanks, I'll have to look into this further.
I'm receiving the error(s) below when trying to install (into a docker container). I'm new to bucklescript (& npm) - do you have any advice on how to resolve?
Can you post your package.json file as well? And do you have a sample github project that we can clone and try running?
I've copied my package.json below in case it's helpful. I'm unfamiliar with the nodejs ecosystem (spent years avoiding it), so I expect I'll be able to resolve this manually with a bit more Google determination and time. I hope it's caused by my inexperience rather than a packaged error.
{ "name": "test-project", "version": "0.1.0", "scripts": { "serve": "serve release", "clean": "bsb -clean-world", "build:bsb": "bsb -make-world", "build:js": "rollup -c", "build": "run-s build:bsb build:js", "watch:bsb": "bsb -make-world -w", "watch:js": "rollup -c -w", "watch": "run-p watch:bsb watch:js serve" }, "keywords": [ "BuckleScript" ], "author": "", "license": "MIT", "dependencies": { "bs-platform": "^4.0.7", "bucklescript-tea": "^0.9.1" }, "devDependencies": { "bs-platform": "^4.0.7", "bucklescript-tea": "^0.9.1", "npm-run-all": "^4.1.5", "rollup": "^0.67.3", "rollup-plugin-node-resolve": "^3.4.0", "serve": "^10.1.1" } }
I'm interested in the js interop capabilities of this project, but in the short term I needed a tea based Material Design solution. To keep momentum I ported the elm-bulma package (md using only css) to bucklescript-tea. In case it's useful for others: bucklescript-tea-bulma
I'm not sure I understand - are you saying JSX views are immutable? I thought JSX functions could respond to browser events and directly change the browser dom outside of the elm update cycle - creating a problem... or is that incorrect?
JSX is just a syntax, it just calls down to the underlying view functions.
And nope, they don't directly call anything, rather what they do is build up a set of 'mappings', and 'later' that is reified to the DOM itself, which is then what sets up the actual events and so forth. :-)
Thanks, I'll have to look into this further.
ReasonML is just a syntax mutator on top of OCaml, it knows nothing about types, it barely knows it's AST, using it literally uses the refmt
program behind it to convert to OCaml as it passes it to the OCaml compiler. Thus all ReasonML code is OCaml code, and 99.9999% of OCaml code can be converted to ReasonML code (a couple of corner cases, might be fixed now though), and refmt
can convert both ways too. :-)
I've copied my package.json below in case it's helpful. I'm unfamiliar with the nodejs ecosystem (spent years avoiding it), so I expect I'll be able to resolve this manually with a bit more Google determination and time. I hope it's caused by my inexperience rather than a packaged error.
I came from the C++/OCaml world, the NPM ecosystem is... interesting, it both has everything and is completely horrifying at the same time, lol... >.>
So the versions look good, script looks good, rollup is awesome to use, etc... etc... Hmm, yeah at this point I think I need a test project that shows the issue...
I'm interested in the js interop capabilities of this project, but in the short term I needed a tea based Material Design solution. To keep momentum I ported the elm-bulma package (md using only css) to bucklescript-tea. In case it's useful for others: bucklescript-tea-bulma
Oh that looks cool! I actually use a HIGHLY modified version of the CSS library myself, which is kind of Material'ish of what can be done with pure CSS without javascript (which is a surprising amount). The original Repo (and links to examples) is at https://github.com/mildrenben/surface although I have an internal version that is significantly enhanced that I've been meaning to pull out into it's own project if anyone might find it useful. I've made a set of bucklescript-tea wrappers to make the special HTML concoctions to make the CSS work and 'look' like javascript even though it's not. ^.^
@j-hotlink Apologies for the delay, somehow I missed this completely—really need to figure out why Github doesn't send me emails for my own projects but spams me for everything else.
I'm not shipping any prebuilt binaries, and instead compiling the PPX during installation using bsb-native. From what I gathered from the logs, the build command is calling the bsb
command from bs-platform
instead of bsb-native
.
I've just tested it with a new project by doing yarn add --dev bs-platform && yarn add --dev ppx-tea-jsx
, and it seems to call the correct bsb
binary under node_modules/ppx_tea_jsx/node_modules/.bin/bsb
. Removing node_modules
and calling yarn
works as well.
Do you have a .yarnrc
somewhere that could affect this? And can you try it with a more up-to-date version of Yarn?
Another thing that would help is to see if bsb-native
is installing correctly in your environment. Does other bsb-native based syntax extensions work for you? yarn add --dev let-anything
or yarn add lenses-ppx
should help you find out. When the installation is successful, you should end up with a binary under node_modules/<package_name>/ppx
.
Thanks for the replies @OvermindDL1!
I'm uncertain if/how the injection of JSX into Vdom.t nodes affects the purity of tea - can you give some pointers on this?
Nope, views are immutable, they should be fine, it's just a mapper from the JSX PPX output to the view calls instead.
I should emphasize that the PPX calls constructors such as Vdom.Node
and Vdom.RawProp
directly, and doesn't use the functions under Tea.Html
or Tea.Html2
(most of the time). In the end, you still end up with the same tree you'd get by calling those functions directly, if you encounter any difference in behavior please file an issue.
Do you forsee any significant issues getting your library to work with ocaml syntax (which I use) rather than reason?
This won't work unfortunately. This PPX works by piggybacking on Reason's JSX support by transforming the [@JSX]
annotations generated by refmt. You can see an example of it here.
For this, a similar approach to ppx_bsx
can be taken. Actually, if ppx_bsx
is adding those annotations at the same locations, running ppx-tea-jsx
after it might work, I haven't confirmed it though. I actually prefer working with plain lists and function calls in OCaml syntax.
I should emphasize that the PPX calls constructors such as Vdom.Node and Vdom.RawProp directly,
Perfectly fine, the functions in those HTML2? modules just do the same. :-)
This won't work unfortunately. This PPX works by piggybacking on Reason's JSX support by transforming the [@JSX] annotations generated by refmt. You can see an example of it here.
How does that work with refmt converting back to ocaml though, All PPX's work on OCaml AST.
I actually prefer working with plain lists and function calls in OCaml syntax.
Likewise yeah, it's clean enough as it is unlike ReasonML.
How does that work with refmt converting back to ocaml though, All PPX's work on OCaml AST.
Yes, but this one looks for [@JSX]
attributes left by refmt. It's documented here: https://reasonml.github.io/docs/en/jsx#tip-tricks
Yes, but this one looks for [@JSX] attributes left by refmt. It's documented here: reasonml.github.io/docs/en/jsx#tip-tricks
So that's pretty expected then. I'm curious how the refmt
ReasonML/JSX -> OCaml actually looks as an example though. :-)
This won't work unfortunately. This PPX works by piggybacking on Reason's JSX support by transforming the
[@JSX]
annotations generated by refmt. You can see an example of it here.
Here is a much better example than the link above:
OCaml output is on bottom left.
<> </>
(Fragment) helps prevent unnecessary wrapping in divs
when we just want to return an array of elements.
Lowercase tags end up like React.createElement("div")
in JS output, while uppercase ones call ModuleName.make
.
Ah very cool, thanks for that! :-)
@j-hotlink Did you ever get to the bottom of this? I'm experiencing the same issue w/ a different reason package that expects bsb
in the postinstall
script to be that of bsb-native
, when it's in fact that of bs-platform
.
I'm also only running into issues when containerizing via the default node container, running atop linux. The local build process on darwin executes normally.
Sorry, I've nothing helpful to add. Although I like the project, other pressures required I KISS with ocaml
Got it. Thanks for letting me know.
Hi, apologies for multiple questions, but as this is the first issue I'm taking a liberty...
I'm receiveing the error(s) below when trying to install (into a docker container). I'm new to bucklescript (& npm) - do you have any advice on how to resolve?
I'm uncertain if/how the injection of JSX into Vdom.t nodes affects the purity of tea - can you give some pointers on this?
Do you forsee any significant issues getting your library to work with ocaml syntax (which I use) rather than reason?
Many thanks.