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

Discussion: Ready for 1.0? #70

Open
jmeistrich opened this issue Jan 17, 2025 · 4 comments
Open

Discussion: Ready for 1.0? #70

jmeistrich opened this issue Jan 17, 2025 · 4 comments

Comments

@jmeistrich
Copy link
Contributor

How are we looking for version 1.0? As of version 0.6.4 it seems like we're at a good level of performance, all features seem to be working well, and I have nothing left on my todo list.

Of course there's still potential for more performance optimization and more advanced features (masonry layout, etc...). But I think as long as we have better perf than alternatives and everything is stable, then we should go for 1.0 asap and build on it from there.

  • Do you know of any issues that should block 1.0 release?
  • Are there any features that don't work quite right?
  • Any props that should be removed because they don't work right?
  • Any features we absolutely need before 1.0?
@michbil
Copy link

michbil commented Jan 17, 2025

For me sticky indices is still quite needed feature, will try to take a look at it over the weekend to asses how big it is.

I also wanted to solve #53, but it looks tricky and I still can not find proper solution to it.

Overall I would like more manual test cases, for example for viewability, various element sizes etc.

Just want to be sure library is usable before releasing 1.0.0 version.

@jmeistrich
Copy link
Contributor Author

Sticky indices would be a great feature! But I think it could come after 1.0? There's lots of people who don't need it, so we can get this to them without it. We can just explicitly call out in the docs that it's not supported yet and is actively being worked on. Looking at your PR it seems like it's a pretty big feature...

Can you share more about the problem that #53 is trying to solve in that thread? I'm not 100% sure what it is - I think it's that when pulling the top to refresh the top item flashes when the new items come in? Maybe I can give it an attempt or throw out some ideas.

Maybe we can launch in the current state as 1.0 beta and ask people to try it, add more example test cases, and share any issues they find? I agree that I'm not 100% sure everything is perfect yet, so maybe more community attention/feedback is the best way to go?

@michbil
Copy link

michbil commented Jan 18, 2025

Sticky indices would be a great feature! But I think it could come after 1.0? There's lots of people who don't need it, so we can get this to them without it. We can just explicitly call out in the docs that it's not supported yet and is actively being worked on. Looking at your PR it seems like it's a pretty big feature...

It was surprisingly easy to hack together, but yeah, making it production ready feature would take a while. I had to convert from FlowType and patch ScrollViewStickyHeader from React Native codebase. Checking that it's backward compatible with other version of RN and web probably would take a while. This should not be blocker for 1.0.0 release

Can you share more about the problem that #53 is trying to solve in that thread? I'm not 100% sure what it is - I think it's that when pulling the top to refresh the top item flashes when the new items come in? Maybe I can give it an attempt or throw out some ideas.

Yes it's about those flashes when adding data to the top. We are using estimates to place unmeasured items, and in most cases it's not a problem when list is scrolling, because it's mostly unnoticeable, but when scroll is standing still it's perceived as a bug.

Maybe we can launch in the current state as 1.0 beta and ask people to try it, add more example test cases, and share any issues they find? I agree that I'm not 100% sure everything is perfect yet, so maybe more community attention/feedback is the best way to go?

1.0.0 beta would be great idea, we can freeze all features for current main branch and focus on bug fixes.

@stevengoldberg
Copy link

Any features we absolutely need before 1.0?

Unless I'm mistaken, part of the functionality from FlashList's overrideItemLayout is missing:

This method can be used to provide explicit size estimates or change column span of an item.
...
Changing item span is useful when you have grid layouts (numColumns > 1) and you want few items to be bigger than the rest.

Emphasis mine. For example, in a calendar view, I have numColumns={7} for the days. However, I need the month headers to span all 7 columns, which I can do with the above FlashList prop.

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

No branches or pull requests

3 participants