I perceive a lack of tutorials and examples about how to setup a modern Haxe JavaScript toolchain, preferably using:
modern front-end libraries/frameworks such as React, Angular or Vue
modern backend frameworks such as Node and perhaps data binding frameworks
unit testing, mocking and coverage tools
The reason I’m asking you to show your build HXML / package.json is because I’d like this topic to contain references to the latest and most popular frameworks to use with JavaScript and the exact way to add this to one’s toolchain.
A build file is an excellent starting point for discussions about a toolchain.
I believe this will be useful to people getting started with Haxe’s JavaScript target.
Extra points if you use VS Code and perhaps can also paste your VS Code tasks file (generated by any extension you may be using).
@mark.knol Ok, it’s not that important really that it is HXML. Basically I’m curious how you set all that up. Can you paste the relevant parts of your package.json? Also, am I to undertand you have some VSCode task that builds the Haxe and another VSCode task that keeps an eye on the yarn dev webserver?
@matthijskamstra Thank you! Useful! And welcome back, thanks for answering my post.
@alex_dja Thanks. And yes, those are some frameworks I’m targeting to use. Wasn’t aware that @kLabz also has a React effort. Happy that there’s a sample in the repo that has a build HXML that shows how to integrate React.
This sample is interesting for academical purposes - it’s a bit old school to use global JS libraries and nowadays you would be advised to look into JS bundlers and managing dependencies using a package.json:
I’ve also been playing with integrating Haxe with Webpack and typescript lately. You can check some of my (WIP) experiments here: haxe-boilerplate · GitHub.
Just be aware that they are mainly a playground at the moment. Some of them use hxgenjs, the others use hxtsdgen to generate TS decl. files. TS can also be used from Haxe by creating externs, though they are not generated automatically like d.ts are atm. They are not really well documented at the moment so feel free to ping me directly if you have questions about them.
I have a more up to date boilerplate that’s supposed to be the product of those experiments. I’ve somewhat successfully integrated coconut.data with plain React (using tsx) through mobx[1]. It uses expressjs in the backend[2]. It provides for a more-or-less sane workflow :). It’s also an example of how to use Haxe and js/ts at the same time in the same project. At the moment the use of webpack is very straightforward and there’s intentionally no use o HMR, although I might look into it later. I hope to share it soon. Actually here’s the repo to my latest TSHX boilerplate experiment: GitHub - fullofcaffeine/fullofcaffeineco-app-boilerplate. I’m working on adding SSR at the moment (from what I see, I’ll need to rework the way the backend is compiled and I’ll need to introduce webapack for the backend too, for it to work*).
You can read more about the motivations behind these experiments here.
*[1] The main reason to do it is because coconut.data is actually very nice for the model layer and while coconut.ui through react works well, it’s still kind of bleeding edge and changing all the time (thanks @kLabz for his awesome work on react-edge though!). I figured it’d be nice to have a way to tap directly into tsx/plain React for UIs and for the rest use Haxe and mix-and-match as needed.
*[2] As I mentioned above, I tried to keep js/ts only in the UI, the rest uses Haxe, even the expressjs web-server. However, I must mention finding good externs for express was a huge pain, and I ended up using the ones from js-kit with some mods to make it work well. It’s still not perfect as you can see here.
Just opening a parenthesis here. I’m not passionate about automated tests (there are enough testing zealots/purists out there and it’s really tiring reading all the gospel about it, specially when it comes to TDD zealots, and testing is code you also have to maintain and that adds to the overhead), but some testing is useful. Be pragmatic, don’t buy into hype, do what you think is useful to let you know when code that is crucial for your app breaks.
@elsassph Thank you! :). Useful! Why would I hate haxelib? (wasn’t aware that lix exists, but I do know that haxelib is not very advanced when it comes to dependency management).
@fullofcaffeine One question. Here, you use -lib react but I can’t see any lib called react in haxe. It’s all react dash something. Am I missing something (or is that hxml missing something hehe see what I did there ).
I managed to add SSR and I’m improving the code a bit. I’m still not 100% sure if it’s worth bridging coconut.data with plain react, but we shall see. The controller inside the sample App.tsx is now a plain react Store class that interfaces the React view with the coconut.data model. I’ll update the repo in the following days.
And welcome back, thanks for answering my post.
).