They're from the standard library, pre-
opened during the compilation of your file. This is why you see them in scope.
You can read more about the Pervasives library in the api documentation:
Most JS libraries should easily work under Reason + BuckleScript.
At this time, we recommend compiling to JS through BuckleScript and use the JS wrappers at reasonml-community or somewhere else.
If you're not interfacing with any library that uses promises, you can simply use callbacks. Everyone gets them and they're performant.
If you need to bind to a JS library that uses promises, or communicate with such library, you can use BS's Js.Promise.
Some of OCaml's language features (not just types) might be able to defer the need for unit testing until later. In the meantime, for compilation to JS, we're working on Jest wrapper. We'll look into using Jest for native too, if Jest is written using Reason in the future (no concrete plan yet). OUnit is a good, small native OCaml testing library right now.
That's the metadata file for editor support. This is usually generated for you; You don't need to check that into your version control and don't have to manually modify it.
Reason/OCaml doesn't require you to write any import; modules being referred to in the file are automatically searched in the project. Specifically, a module
Hello asks the compiler to look for the file
hello.ml (and their corresponding interface file,
hello.mli, if available).
A module name is the file name, capitalized. It has to be unique per project; this abstracts away the file system and allows you to move files around without changing code.
They're ordinary variants/records/module definitions that come with the standard library,
opened by default during compilation out of convenience.
Say you have
List.map(item => 1, myList);. The argument
item isn't used and will generate a compiler warning. Using
_ => 1 instead indicates that you're intentionally receiving and ignoring the argument, therefore bypassing the warning. Alternatively,
_item => 1 has the same effect, but indicates more descriptively what you're ignoring.
MyModule is a module's name,
t is a community convention that indicates "the type that represents that module, whatever that means". For example, for the
String.t is the type carried around and representing "a string".
Why is there a
Js_promise and then a
Js.Promise? What about
Js_string and whatever else?
As a convention,
Js_foo is the actual module, and
Js.Foo is just an alias for it. They're equivalent. Prefer
Js.Foo, because that's the official, public module name.