Add LRU cache

[aleclarson]

Possible reference implementations:

• https://github.com/lukeed/flru/blob/master/src/index.js
• https://github.com/sindresorhus/quick-lru/blob/main/index.js
• https://gist.github.com/aleclarson/1cb5095410eb110a3eb042969d62ab12

[adamhamlin]

Just my 2 cents, but this type of utility feels a little too complex/involved to build ourselves. As a developer, it's the kind of functionality where I would specifically want to seek out a dedicated library because I'm looking for something deliberate and focused--not an add on.

I noticed that you removed the following blurb (from radash) in radashi's contribution guide, but I still think it's a good rule of thumb and would apply to this situation:

If an implementation needs more than ~20 lines of code it might be better suited for another package or library. This is another softer rule

[aleclarson]

Hey, I appreciate you sharing your thoughts on this. You've raised some valid points about complexity and the appeal of dedicated libraries. These are definitely important things to consider.

Just my 2 cents, but this type of utility feels a little too complex/involved to build ourselves.

If you look at flru's implementation, it's not as bad as it sounds. :)

As a developer, it's the kind of functionality where I would specifically want to seek out a dedicated library because I'm looking for something deliberate and focused--not an add on.

Hmm.. I wonder what's not deliberate about having it in Radashi? Also, what is the benefit of it being the sole focus?

I think, in many cases, a simple implementation works just fine. And if your needs aren't met in some instance, then go find something more full-featured (or fork Radashi's). The only time I wouldn't say this is if there's some kind of “vendor lock-in” where rewriting code to another tool (once your needs outgrow the simple tool) is expensive. But I don't think any function in Radashi would meet that criteria, since we try to keep things as simple as possible.

A quick idea: Perhaps a good route to take is trying to mirror the bare essentials of the most full-featured, high-quality NPM package there is. The goal being to adhere to its API design, so replacing the simple Radashi implementation with that full-featured package is as easy as possible.

I noticed that you removed the following blurb (from radash) in radashi's contribution guide, but I still think it's a good rule of thumb and would apply to this situation:

If an implementation needs more than ~20 lines of code it might be better suited for another package or library. This is another softer rule

20 lines seems a bit arbitrary. I think it should be gauged on implementation complexity instead. If a semi-experienced developer has trouble grokking the implementation in less than 10 minutes, we either need to add more code comments or consider removing the function. Of course, 98% of our functions take much less time to grok. The biggest offender is probably the traverse function I added.

I guess what I'm trying to say is that readability is a better measure than lines of code. But I definitely want to avoid any excessively big functions, as this is an indicator of scope creep and implementation bloat.

[adamhamlin]

If your intent is to make a barebones implementation (for this issue specifically or for similar utilities that might return an instance of some Radashi class), then I withdraw my objection--since that is not complex, involved, or long (code-wise). I was assuming you were trying to "compete" with something like node-lru-cache, which has MANY configuration options, additional time-based eviction strategies, resource clean up, etc. But I hope that if/when enhancement requests come along for this cache like "Can we add an option to...", we treat that with an appropriate level of restraint and yeah just direct people to another library.

Perhaps a good route to take is trying to mirror the bare essentials of the most full-featured, high-quality NPM package there is. The goal being to adhere to its API design, so replacing the simple Radashi implementation with that full-featured package is as easy as possible

Yes, agree

20 lines seems a bit arbitrary. I think it should be gauged on implementation complexity instead

I think it should really be both. Complexity and code length may be correlated, but there exist "simple" utilities that are long and/or may rely on multiple internal classes, and I'm skeptical that such things would make sense in Radashi 🤷

All of this to say, perhaps it highlights 2 flavors of Radashi utilities: (1) Things like range, where we're trying to have the "best" range function out there; and (2) things like this where we want to provide like a basic "free tier" implementation--but we're not going deeper than that or trying to compete with other, dedicated packages in the same problem space.

Is that a fair description?

[MarlonPassos-git]

Just my 2 cents. As @adamhamlin said that if we are going to create simple implementations of a function/class, we should explicitly state in the JSDoc function and documentation that this is a simple implementation of x. If you need something more complex or performant, look for those packages.

[aleclarson]

I think it should really be both. Complexity and code length may be correlated, but there exist "simple" utilities that are long and/or may rely on multiple internal classes, and I'm skeptical that such things would make sense in Radashi 🤷

Definitely agree with not relying on internal classes. One of Radashi's principles is to not have internal-only functions or classes.

I think we'll have to take it on a case-by-case basis. Some things simply require more code to be implemented, even without a ton of option bloat. That said, I think we agree on the general soft rule of "keep it short, keep it simple".

All of this to say, perhaps it highlights 2 flavors of Radashi utilities: (1) Things like range, where we're trying to have the "best" range function out there; and (2) things like this where we want to provide like a basic "free tier" implementation--but we're not going deeper than that or trying to compete with other, dedicated packages in the same problem space.

Is that a fair description?

I don't know if we can reduce it to just 2 flavors. It might sound counter-intuitive, but the better approach might be to explicitly state only what we're not trying to do, rather than try to categorize what we have. For example, as you said, we're definitely not trying to reimplement existing, complex, cover-all-possible-needs NPM packages. That much is clear.

Whether we add an option here or there really depends on how crucial it is (i.e. how often people find themselves ditching the Radashi version in favor of a fully-featured alternative). If we can implement a new behavior in a separate, self-contained function, that would be ideal. But increasing the number of highly-similar functions in Radashi also comes at a cost, in terms of cognitive overhead, so it's not always an easy decision.

If a function can somehow be both fully-featured and simple, of course we'll want to do that. But that's pretty rare, I'd say.

I hope that helped clarify my thoughts a little more. 😄

[adamhamlin]

Yes thanks, it does clarify things, and I think we're basically on the same page--even if this thread may not read that way. And I'm not trying to constrain to 2 utility flavors per se, just highlighting that a "restrained" implementation as with this LRU cache example feels new/different compared to the more prototypical, static, transformation-based utilities which seem generally "complete".

But yes also agree with @MarlonPassos-git that we should call out any such limitations/decisions in the JSDoc.