IMHO, it's a matter of not being familiar with such way of writing code. Once you wrote a few lines yourself, it becomes much easier to read such code.
Anyway, I'm advocating to use it with caution, not in a "pointfree all the things" manner.
It's possible to use Ramda with TypeScript, although it's not perfect. It actually shows some weaknesses of TypeScript's type system as it's not possible to properly type some functions.
Sure, pointfree style has been present in RxJS since version 6 but on a different level. The article is about using `pipe` for composing functions that you pass as arguments to RxJS opertators. RxJS's `pipe` is about composing the operators themselves.
Author here, thank you for some interesting points.
I think it depends on one's personality. I wrote the app because I needed something like this myself. There are many friends that I love to meet but I don't because of poor time management on my side and/or bad memory. The app is meant to help in such cases.
Author here. Thank you for some great feature ideas! Currently, it's implemented as a PWA so integrating with the phone book is not an option. However, it should be fairly easy to do with hybrid app approach. I will give it a thought.
Thanks, these are some nice ideas. However, I specifically didn't want it to be marketed as a tool for sales since then how would you differentiate it from a CRM?
Thank you, it's really helpful. I have very little experience with UX so I decided to start by sticking to the guidelines.
But what you are saying makes a lot of sense and I will definitely look into doing some tests with real users.
I will add some text to show in case of empty list. I agree the button (FAB) is difficult to find on large screens but it is part of the Material design guidelines (https://material.io/guidelines/components/buttons-floating-a...). I will think of some other approach.
True, I wrote something similiar in the conclusion section. However, you can easily imagine a scenario when you need to perform some complex validation that cannot be handled by Firebase rules but it doesn't justify having to maintain a server.
The implementation in the tutorial is just an example - I wanted to provide a starting point for people who want to do something more complex.
I agree on the first point. As to the second, I didn't mean that having flatmap is the reason why we can combine Options and Lists. I meant that Options are composable with other Options and Lists are composable with other Lists.
I understand the problem of working with different monads. I looked into monad transformers at some point and found them difficult to work with so my approach now is to avoid mixing monad types (for example instead of having Future[Option[T]], just use a failed Future instead of None).
[Author] I wasn't trying to say that Option monad is better/worse than null conditional. My point was to compare two different approaches to the same problem.
Anyway, I'm advocating to use it with caution, not in a "pointfree all the things" manner.