fpdart v1.0.0 about fpdart

[cranst0n]

I've recently published an set of FP related packages using Dart 3. While I use them for work and hacking on, I don't have any interest in creating yet another FP library since there are already plenty of good ones around, fpdart among them. I think there are some things in what I've built that could be useful additions to fpdart.

You can find the repo here

Among things it includes that may be worth considering for fpdart:

• IO monad closely derived from the cats-effect IO
• Retry cababilities for IO closely derived from cats-retry
• IList and related NonEmptyIList. These ended up being wrappers around the excellent FIC IList for performance reasons, so their addition is probably more debatable
• Validated
• Various syntax extensions leaning on Dart 3 tuples
• JSON library closely derived from circe
• Binary codec library closely derived from scodec
• Lens library closely derived from monocle
• Units library closely derived from squants

The main limitation of what I've created is the lack of documentation, and in some cases the lack of thorough tests, both of which, fpdart excels at.

I also made an attempt to port fs2 to dart but ran into limitations in the dart type system (or maybe my own limited knowledge of it).

Maybe some of this stuff would be a good fit in fpdart but at the very least, I hope it can provide some ideas on how to move to v1.0.0.

[SandroMaglione]

Hi everyone,

I am aiming for releasing fpdart v1.0.0 next week 🚀

Comment below for any last suggestion or issue 👇

[FaFre]

I would really like to have the option to only import the core functionality of fpdart like Either, Option etc.

I only use a small subset of the fpdart library and sometimes I accidentally use unintentionally the exposed fpdart extensions for List, Iterable etc. which I don't intent to. E.g. fpdart's all instead of the dart core's every. Confusion sometimes happens when you code in multiple languages.

I know that I would have the possibility to work with hide and show, but a more comfortable solution would be maybe having a specific import like import 'package:fpdart/core.dart'; for that.

[FaFre]

Everything, but global extensions for types that are not having their origin in fpdart themselves.

[SandroMaglione]

@AdamHavlicek actually is not that id was renamed to identity, but that fpdart previously had both id and identity which did the same thing. As @Musta-Pollo says, in order to avoid conflicts and confusion with the same function with 2 different names, id has been remove in favour of identity.

[SandroMaglione]

The first beta release (v1.0.0-beta.1) has been released.

Feel free to provide any feedback and report any issue here 👇🙏🏼

[SandroMaglione]

@Musta-Pollo thanks for reporting, this should have been fixed in #122

[RandalSchwartz]

!!!!

[RandalSchwartz]

Just off the top of my head, but I was thinking that an easy way to go from the existing Tuple monad back and forth to a Record (T1, T2) would be great. We can never turn the records into monads, so there's always going to need to be a way to lift from records into proper monad space.

[SandroMaglione]

@RandalSchwartz I think that in practice using Records would lead to a better developer experience and easier maintainability than Tuple in dart 3.

What practical use do you see for having Tuple as monad? What do you think would be a good reason to have and use Tuple instead of Records in Dart 3?

---

Update: Removing Tuple2 aligns better with native dart code, as well as making the code less verbose and reducing lines of code in fpdart (PR)

[RandalSchwartz]

Another thought... I think your next release should be still under 1.0, because there will likely need to be a few breaking changes while you are absorbing the proper best practices about the new features. I'd hate there to be version 2.0 in six months, but I'm willing to live with 0.9 and 0.9.1 etc.

[RandalSchwartz]

Update: Removing Tuple2 aligns better with native dart code, as well as making the code less verbose and reducing lines of code in fpdart (PR)

Yes, I completely agree, looking at the work you did in the past few days. Much cleaner to not even need the artificial class. It just means I need to do some work for one of my clients to advance fpdart for them. :)

[SandroMaglione]

@FaFre how would you suggest to split imports? What do you think core.dart should contain?

[RandalSchwartz]

Everything, but global extensions for types that are not having their origin in fpdart themselves.

I like this. And yes, I'd call "core" everything but the extensions. I presume that none of the extensions are used by any of the core.

[Musta-Pollo]

Thank you for the incredible update ❤️!

I wanted to bring to your attention that the links to the examples in the documentation are not functional. An example can be found here:

[TC3000]

Could we please have a better way of handling streams in V1? There was a suggested approach here #27 (comment), curious to hear your thoughts.

[AdamHavlicek]

hello, why id was renamed to identity? it adds unnecessary breaking change to api.

[Musta-Pollo]

hello, why id was renamed to identity? it adds unnecessary breaking change to api.

Personally, I am glad about this change because I had a lot of name conflicts when importing the fpdart. I would need to use:

import '...fpdart/fpdart.dart' hide id;
And that was not ideal.

[FaFre]

Will you address the suggested change mentioned in #108 (comment) ?

[SandroMaglione]

@FaFre I would prefer not to add multiple imports to avoid adding complexity when setting up and using the library. Many people that use the library for the first time I think would benefit to have everything at their disposal, especially since you can learn about a new functionality by using auto-complete.

Furthermore, in v1 the extension methods have been refactored to improve performance.