Active maintainers wanted!

[aleclarson]

The goal of Radashi is to continue the vision of Radash under new leadership, so it can receive the love and attention it deserves. Early in Radashi's life, backwards compatibility is critical, so Radash users can easily migrate.

If you can afford dedicating some time to reviewing PRs, closing issues, or even contributing your own features and fixes, Radashi wants needs you on its team of maintainers.

What's expected

As a maintainer, you're expected to uphold the original vision of Radash. Beyond that, it's up to you how much time you will dedicate to Radashi.

Ideally, you've submitted pull requests to Radash or Radashi already, and so you've demonstrated the requisite knowledge and aptitude.

How do I join?

Comment here, along with any PRs you've submitted or work you've done on your own fork of Radash. Anyone who applies will be added to the team and given a chance to show their worth.

Inactive maintainers will be removed after a grace period of 3 months, but don't worry, you can always rejoin if you find the time to help out in the future.

[localusercamp]

vision of Radash

Does this include polymorphism prohibition? =)

I think something like this could improve DX pretty much.

sort(users, user => user.id);
sort(users, 'id'); // support keyof

[localusercamp]

In the case of your sort example, I would argue the polymorphism is acceptable if the use case is especially popular.

I think that is what it is - the most popular use case of specifying one property name (which we could easily do in TS) instead of creating a bunch of functions which only return a single property.

Second thing is how do you know what is more popular before implementing it? =D
I think the best answer is look at similar libraries. Laravel, Lodash, Vue are implementing such polymorphism in one way or another and many people use "shorthands" instead of defining small functions.

In my opinion if all the user need is to filter/sort/etc by single a field the most convenient way is to give him the ability to pass a string. If he wants a more complicated logic he always can use function. And that's it.

P.S. Make some function accept array, string, number, function, and so on is awfull. That's why I did not like Lodash.

I'll be glad to be involved into this project. I thinking of make nuxt module for this repo, what do you think?

[aleclarson]

I think that is what it is - the most popular use case of specifying one property name (which we could easily do in TS) instead of creating a bunch of functions which only return a single property.

One thing to consider is how trivial it is to implement this on your own:

import * as _ from 'radashi'

export const sortByProperty = (array, prop) => _.sort(array, obj => obj[prop])

But if this shorthand signature is indeed popular with >50% of Lodash users, then you'd be right that it's still worth including.

I have a PR almost done that will add such functionality to sort and similar Radashi functions.

[aleclarson]

P.S. Make some function accept array, string, number, function, and so on is awfull. That's why I did not like Lodash.

Good, we're on the same page there :)

I'll be glad to be involved into this project.

Cool, Radashi would appreciate another brain on the team! Let me know if you'd like an invite.

I thinking of make nuxt module for this repo, what do you think?

Yeah, that sounds like a cool idea. Do you wanna create a new discussion about it where we can discuss the idea further?

[localusercamp]

Do you wanna create a new discussion about it where we can discuss the idea further?

Yeah, I'll create one when I get some time

[localusercamp]

Let me know if you'd like an invite

Give it to me! =)

[stefaanMLB]

I support @localusercamp.
In my experience, most users are not interested/willing/able to fork a library and keep the fork in sync with the main library. Most are just looking for functionality and will most likely appreciate the alternative in the example.
@aleclarson I much appreciate the thoughts you put into this.

[localusercamp]

In my experience, most users are not interested/willing/able to fork a library and keep the fork in sync with the main library.

Yeah, fully agree.

[aleclarson]

I assume you're referring to what I said below?

The great part is that Radashi is even easier to fork via copy-pasting than Radash is, because of its modular nature and internal use of import {…} from "radashi". If you want more polymorphism or less, it should be simple enough to copy-paste the function and add the polymorphism yourself (possibly using other Radashi functions to make your changes easier to implement).

The keyword is "copy-pasting". It's very easy to copy a function from Radashi and paste it into your project as its own utility. That means there's no notion of keeping it in sync with upstream.

[stefaanMLB]

OK, the user of the library can start out by copy-pasting but soon enough he/she will want to keep the code in sync across his/her projects and end up creating an NPM module anyway (thus a fork of the library).
Next thing is to keep the shiny new module up-to-date with changes in the parent library
Next thing he/she will try to have his/her improvements integrated into the parent module to avoid the work of keeping the own module up-to-date with the parent.
This is what happened to me and I guess it's also why you created radashi because radash isn't accepting PR's.

Granted, the copy-paste option is an alternative and will-suited for people who have a limited number of projected to maintain.

[aleclarson]

I understand the concern. While we can't meet everyone's needs, we should try to support at least what >50% of the community will use. Of course, it's hard to gauge that figure, so there's some guesswork required.

I will say that even if you copy-paste 10+ functions from Radashi, you can publish your own package with those customized functions without maintaining a fork. Simply add radashi to the package's dependencies and the only thing you'd ever need to update is the version number (like any other dependency).

You could even make radashi a peer dependency of the package, so the root project is in control of its radashi version. Then you only need to update your “pseudo-fork” when changing the behavior of your own code or upgrading to a new Radashi major.

Finally, your package could forward the exports of radashi and override the ones you needed to modify. This is all very straight-forward these days.

export * from 'radashi'

// Override `select` from radashi with my own version.
export * from './array/select'

[stefaanMLB]

OK, valid point. I suggest to put this in the radashi documentation.
I use Typescript for 7 years and it never occurred to me to do this. Others may not know either.

[Minhir]

Hi @aleclarson, thanks for your activity to save that nice library!

I love a simplicity of radash API compared to lodash, and I prefer it as util library in my projects. But it still has a big room for improvements. I'll be happy to help with code reviews and coding, though I don't have too much dedicated time for it.

[aleclarson]

Great to hear you're interested in helping out. Given your familiarity with the project and the helpful code reviews you've done, we'd be glad to have you on the core team. No worries about limited time availability - any involvement is valuable. Want me to add you?

[Minhir]

Yes, sure!