Things that don't belong here

[mlms13]

...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 or bs-fetch
• [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.

[andywhite37]

:+1: Yeah, maybe we can make relude-color and relude-url

[phated]

😂 😂 https://github.com/reasonableconsulting/url - feels like we are all working on very similar things 😂 😂

[mlms13]

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.

[jdeisenberg]

Years ago I did some work on https://metacpan.org/pod/Date::Calc, which has a lot of interesting functions.

[andywhite37]

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.

[mlms13]

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.

[mlms13]

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.

[andywhite37]

If we make relude-color I suggest we shamelessly steal everything from our friend fponticelli/thx.color

[esbullington]

What about a lens implementation? Have you all considered that? (prob as a separate library in reazen, not in Relude itself).

[andywhite37]

@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.

[alavkx]

Small suggestion — it would be nice to have relude-* accessible from the docs. Or maybe an "awesome-relude" repo will pop up... 😆

[rolandpeelen]

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

[andywhite37]

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.

[rolandpeelen]

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