Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Full scale rewrite #124

Open
diogofcunha opened this issue Apr 13, 2020 · 3 comments
Open

Full scale rewrite #124

diogofcunha opened this issue Apr 13, 2020 · 3 comments
Labels
enhancement New feature or request

Comments

@diogofcunha
Copy link
Owner

diogofcunha commented Apr 13, 2020

React change a lot since I've start this project, I'm thinking about undergoing a full re-write that will hopefully create a more descriptive and easier to understand codebase and better architecture overall, a few of the hightligths

Typescript

By the time I started this project I was already very proficient in typescript but the boilerplates that did have typescript support built in were still catching up. I been doing solely typescript for over 4 years now and I can say with pure confidence that using it as the primary language for this project will help in contributions, bug reductions and documentation needed

Move away form nwb

I did use nwb as a boillerplate for this project, ended up regreting that decision as the project has been pretty much abandoned for a while (altought it seems to be back on its feet now). Controling our own build stack and tooling will make further changes (like using typescript) a lot smoother and also stop vulnerability warnings on dev dependencies that can't really be controlled by this project

Hooks everywhere 🎉

At this stage I fell confortable enough with hooks to write a spot on api that can make everyones life's much easier

Even better performance and more customization

Perfomance for this library was always one of the most celebrated features but I personally fell we can do a better job overall, this may require a few hard breaking changes but I do fell like moving away from some of the initial legacy will help adoption and make everyone's life's happier

New and simpler website

Shout out if you want to help in designs or actual implementation (with codesandbox live editing enabled 😎), everyone is welcome.

Considering use of react-window instead of react-virtualized

react-virtualized will always be the defacto library when it comes to virtualization in react but after trying react-window (from the same creator as react-virtualized) I must say I'm pretty impressed, the api is a little bit more intuitive, the lists seem faster and the overall lib size is tiny when compared to the conterpart, this is a transition I'm seriously considering.

And this is it, if you want to help just give me a shout and I will be happy to find you something to do, the initial works may start in a different repo and later be merged here to avoid breaking changes and huge unrevieweble pull requests.

Cheers
Diogo

@diogofcunha diogofcunha added the enhancement New feature or request label Apr 13, 2020
@underfisk
Copy link

Well i think this is really a great way to improve this project, I have already cloned your project months ago and started transforming it to typescript, got rid of nwb and made tree-shaking work even better and supporting RxJS for search/updating and also transformed into hooks.
It is a closed package now and used for a specific project but i think if you turn this into typescript, you should also consider providing a more sophisticated API and allow more customization onto the list.
Another thing you could also do, I have already done it myself is to provide utilities to update the nodes and manage active/hover states that many people will use for sure

@arminyahya
Copy link

Hi. I have a fork from this repo and I have changed the code to use react-window.

I was able to use react-window in all samples except one:

NodeMeasure.

react-window doesn't have CellMeasure.

I think there are people who installed this package and they are using a dynamic height tree.

I think we should separate this repo into three:
react-virtualized-tree-core
react-virtualized-tree
react-virtualized-tree-windowed

both react-virtualized-tree, react-virtualized-tree-windowed have dependency to react-virtualized-tree-core.

with this approach users who are using react-virtualized-tree package stay safe.

for example, I want to use react-virtualized-tree and I'm using react-window in other lists inside my project.
I do:

npm i react-virtualized-tree-windowed

if I need to have the benefit of CellMeasure I should use main instead:

npm i react-virtualized-tree

of course, there are some other features in the react-virtualized-tree version which can be implemented

@diogofcunha

@gormonn
Copy link

gormonn commented Oct 3, 2021

@diogofcunha Hooks!
Hooks would be very useful, because we do not always use react-virtualized for virtualization - this will allow us to use hooks outside the library context - only for data

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants