relude
relude copied to clipboard
Things that don't belong here
...or maybe they do, idk. But these are some utility libraries that I'd like to have a "de facto" standard for.
- [x] URL
-
relude-url
- fully typed
- easily append path, query strings, etc
- convert to/from ReasonReact Router URL type
- might depend on
relude-parser
for parsing URLs
-
- [ ] Color
-
relude-color
- Output as hex, rgb(a), hsl(a) strings
- Blend, darken, lighten, and other transformations
- Anything else in Elm.Color or any other common Color libraries
-
- [x] Simple monadic parser library
-
relude-parser
-
- [x] AJAX/Fetch utilities
- Need to get
IO
to a stable state first - Bindings to browser-based
fetch
orbs-fetch
- Need to get
- [x] Dates
- Represent local date (and time) with no timezone
- Have a type that turns a local date into an instant (precise moment in time)
- Minimal utilities for converting to/from
Js.Date.t
- Formatters that don't depend on magic strings
- [ ] Lenses
- [ ] Streams
- Check out Scala FS2 for ideas
- Also check Haskell, Purescript and Elm ecosystems (or any other things) for ideas
- [ ] RationalJS Future interop library (with IO)
- Not sure how critical this is, but might be helpful to somebody?
- [ ] Data structures
- [ ] Stack
- [ ] Queue
- [ ] HashMap/HashSet/hashing library
- [ ] Heap
- etc.
:+1: Yeah, maybe we can make relude-color
and relude-url
😂 😂 https://github.com/reasonableconsulting/url - feels like we are all working on very similar things 😂 😂
Throwing dates on the list... we have a small date library internally at work that I'd love to build out as an open source thing.
Years ago I did some work on https://metacpan.org/pod/Date::Calc, which has a lot of interesting functions.
I'm kind of wondering if we could justify putting the date/time, URL, and parser stuff in the core relude
library. The main reason is to avoid the ecosystem versioning hell, and also because the majority of front-end apps tend to work with URLs and date/times in some form. I would put the parser stuff in core too, because it would nice to be able to write proper parsers for URLs and date times, and have the parser tools available in other projects without the fuss of managing more installs.
We could always start off with these things in core, and then move them out if needed.
The color
stuff still probably belongs outside, because manipulating colors is probably not a core concept in most apps.
The only downside I see is a psychological one:
- Person A: "Js.Date is terrible, are there any good alternatives in Reason?"
- Person B: "Relude has a pretty decent date library built in."
- Person A: "Hmm, not sure I want to use a whole stdlib alternative just for a couple date functions."
I think people are slightly more likely to try out relude-date
if it's a specific package that meets a specific need, instead of bundled into something larger. Which is silly... the net effect is that either way, Person A's project will directly or indirectly depend on relude
and any half-decent dead-code-elimination tool will produce roughly the same bundle in the end.
Anyway, not sure if this is something we actually care about, but it's the only reason I can think of for not bundling everything together in relude
.
relude-url
and relude-eon
now exist, and while there's still plenty of work to be done there, I'm checking them off of this list because we're not likely to forget about them, now that we have dedicated libraries.
If we make relude-color
I suggest we shamelessly steal everything from our friend fponticelli/thx.color
What about a lens implementation? Have you all considered that? (prob as a separate library in reazen, not in Relude itself).
@esbullington - yeah, that is a great idea. I know there are some lens implementations out there, but I haven't looked at them too much, but I agree it would be nice to have something, or figure out which other library works the best with our stuff and wrap it (if needed). I'll add it to the list above.
Small suggestion — it would be nice to have relude-*
accessible from the docs. Or maybe an "awesome-relude" repo will pop up... 😆
Quicktest is also something I'd love to have at some point! Did not find anything for fuzzy testing in Reason. There is some prior art here: https://github.com/c-cube/qcheck - Not sure of the amount of work involved
Quicktest
Yeah, that was something we always wanted to investigate. bs-bastet (the underlying FP types/interfaces lib) has some of that kind of testing, but it's been awhile since I've looked at it.
I see lenses in this list. I was looking for a lens library too. I noticed the lenses-ppx
, which worked in a rather odd way with sum types... We had a little hackathon at work and I decided to write a ppx that adds the simpler getter / setter functions like here: https://github.com/jonlaing/rationale/blob/master/src/Lens.re
Literally the first steps right now. Working with it locally works as long as you build the PPX manually first. Release mechanism I want to borrow from the Decco guys / push it into a GH action for Linux / MacOs, but that's not working as of yet. I'm currently working on stuff to make it work with option
and result
too. I've added some escape hatches. Seems to be working rather ok for now. Would love some input!
See the Array / List / Result / Option stuff here: https://github.com/rolandpeelen/bs-pancake/pull/1