petercrona
commented
4 years ago I started to look a bit, and, in general nice to get TS in there :)
I moved ladda-fp, ladda-observables and ladda-logger from external repos into this one. It makes no sense to maintain these as separate artifacts, having them in here makes it easier to typecheck across all projects. I did not attempt to convert ladda-fp yet, since I believe that most of it will become obsolete anyway.
Please leave these out! They are out of the core for a very deliberate reason. Ladda-FP is used for multiple projects/plugins. Ladda-observables is not part of the core because it violates https://www.ladda.io/#low-buy-in . The fundamental idea of Ladda is to reduce accidental complexity by eliminating the need of this sort of cache handling in the application code. There's just one touch point (where the API calls are decorated). See for instance https://github.com/SmallImprovements/ladda-example-crud/search?q=%27ladda-cache%27%3B&unscoped_q=%27ladda-cache%27%3B . Ladda-observable is really useful, but, it does violate this by potentially changing (at SI it clearly did) how people write their application code.
Ladda-logger could be argued if it could be in the core, but, we rather chose to not put it there to keep the core as small and simple as possible. Note that Ladda is designed specifically to support this, that's why even the cache is a plugin - to make sure we treat plugins as first-class citizens.
Changed code to something semantically identical in a few places, where we went a bit overboard with the abstractions. Removed unnecessary currying.
Sounds good, but a bit tricky to see where / what changes. Perhaps you can give some pointers to where? Note that for the currying, we curry by default to encourage functional programming. I know you're not a fan of FP, but, as you've noticed, Ladda is coded in a FP style and there's no plan to go away from that at the moment - this has not even been discussed. You could see getting into Ladda as an opportunity to pick up some FP :) I'm always open for arguments for why going procedural or OO would be better, but, as I see it, you can do good with any paradigm. For now, we even mention FP at the main page: https://www.ladda.io/#quality
I actually have a todo to make Ladda TS - so this is very appreciated. My idea was to do a rewrite from scratch though, since having a type system can influence the design - but given that it is hard to find time, especially as a parent (since I work on Ladda mainly in free time), adding TS on top might be a good compromise. And, now when "requirements" are quite clear, it's quite easy to get a very clean implementation.
I did not attempt to convert ladda-fp yet, since I believe that most of it will become obsolete anyway.
As mentioned, there's no plan to go away from FP in Ladda at the moment. Of course, the discussion can be had, but, so far this hasn't been discussed at all?
This PR lays the groundwork for bringing ladda to the present.
I've tried to do little more than the most straightforward conversion to typescript. A few exceptions are:
The immediate goal with this PR is to have the TS version work in praisemanager. We can observe potential problems there, and then improve the actual code here, simplify things and fix bugs.
The PR is large, but can be reviewed commit by commit and most of the changes are straightforward.