You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hey @SandroMaglione, thanks for this great package and the great upgrade incoming with the Effect strategy that has been widely validated in the TS ecosystem.
I'd like to know if you're planning to provide (somewhere in the future) custom lints on top of this package's API? When we are adding this package (or any other fp package such as either and dartz) to projects with multiple collaborators, there will be peers that won't know about all the possibilities of this package and the implications of using each "functionality", neither why it's being used in such scenarios.
To give a little bit more context, when we get closer to the core of pure functional programming, it is not a common knowledge amongst many people when comparing to OOP. We can see that here in practice with the new Effect API, that aims to remove most of the fp "glossary" out of the way to mitigate friction for new users. This is even more impactful because we are talking about a object-oriented language, Dart.
So, a lint would make this friction even less severe for such scenarios, providing local suggestions (and link to explanations) on why we should use Either instead of try/catch or Task instead of Future, for example. Not only the fact that it makes the whole codebase consistent, preventing different standards for the same "problem". I know that people may be okay with an inconsistent codebase, where some implement using the FP approach and others the "native" one, but I digress.
I am open to help doing this if you'd like, but I wanted to hear your opinion on this matter first - thanks.
The text was updated successfully, but these errors were encountered:
Yes, there was already an idea of providing custom lints for fpdart. In fact, there is already a fpdart_lint folder ready for a possible implementation.
It's now better to wait for fpdart v2 before adding support packages to fpdart. Once the new fpdart core is released as stable we can start working on tooling.
Hey @SandroMaglione, thanks for this great package and the great upgrade incoming with the
Effect
strategy that has been widely validated in the TS ecosystem.I'd like to know if you're planning to provide (somewhere in the future) custom lints on top of this package's API? When we are adding this package (or any other fp package such as
either
anddartz
) to projects with multiple collaborators, there will be peers that won't know about all the possibilities of this package and the implications of using each "functionality", neither why it's being used in such scenarios.To give a little bit more context, when we get closer to the core of pure functional programming, it is not a common knowledge amongst many people when comparing to OOP. We can see that here in practice with the new Effect API, that aims to remove most of the fp "glossary" out of the way to mitigate friction for new users. This is even more impactful because we are talking about a object-oriented language, Dart.
So, a lint would make this friction even less severe for such scenarios, providing local suggestions (and link to explanations) on why we should use
Either
instead oftry/catch
orTask
instead ofFuture
, for example. Not only the fact that it makes the whole codebase consistent, preventing different standards for the same "problem". I know that people may be okay with an inconsistent codebase, where some implement using the FP approach and others the "native" one, but I digress.I am open to help doing this if you'd like, but I wanted to hear your opinion on this matter first - thanks.
The text was updated successfully, but these errors were encountered: