Post

Legend List 0.1 is ready to test! This is an early experiment to see how well it works in real apps so please post issues and/or PRs 🙏. It’s only ~600 lines so it should be easy to understand and tweak. ✨ 100% JS ✨ Fast ✨ Dynamic sizing ✨ Works in both new and old arch

20/11/24, 5:37 pm15 reposts105 likes

Install: bun add @legendapp/list Repo: github.com/LegendApp/le... Big thanks to @cedric.dev for helping with great ideas and being an @expo.dev wizard!

github.comGitHub - LegendApp/legend-listContribute to LegendApp/legend-list development by creating an account on GitHub.

It surprisingly seems to work well in old arch too, and still seems faster than other lists 😀. Needs a lot more testing and benchmarking though... There's still more optimizations to be done, but I'm very curious to see how it works for you!

On old arch? I thought you achieved perf via sync onLayout? Have you played with it on Web at all? Happy to drop it into @guild.host & can pair on that too if you need a guinea pig 😄

Perf is more from legend state's targeted small renders 😃 I tested web only briefly. It seems to work at least, but not sure how perf compares to others. We may be able to do some web specific optimizations with things like ResizeObserver. I'd love to try it in guild!

@ashtonlance.com

Impressive! What inspired you to write a new List component for RN?

It was @mojavad.bsky.social's talk on new architecture at @reactadvanced.gitnation.org that gave me the idea, then I prototyped it on a train ride and it was surprisingly good 😅

This looks great, will test it later today.

would it be possible to do a version that doesn’t require the -state dependency? it seems like it should be possible to write the same windowing logic with imperative re-renders that don’t introduce an observable abstraction in the middle. not sure if you feel super strongly about it!

it implies buying into the -state model which feels dicey to me (so far i’ve only had to remove these kinds of observable bindings from codebases i worked in — and people have been creating them since 2014). plain react components tend to outlive these abstractions & work with all react features

i might be missing something though! curious if you consider this part essential to it and how exactly that manifests — couldn’t quite understand it from reading

Yes, absolutely. This was the easiest way for me to prototype and experiment with minimizing renders and get something out asap, but I’m planning to change it to do it imperatively so I can remove the dependency. I’ll try to release an update in the next few days.

@nanniii.bsky.social

100% js means we could get a similar api as web and be able to do pagination ui for lists like Urql suggest ??

@unintuitive.com

Super hyped to try this. My hobby project (which has a demo mode) uses FlashList and it's annoyingly janky guardianghost.com will try and use it this weekend

guardianghost.comApp Showcase

Let me know how it goes!

@frankcalise.dev

Will be trying this out on a client project with heavy list rendering, maybe Friday or early next week Nice work!

Awesome! Let me know if you encounter any issues and will fix asap.

@kabanks.bsky.social

Ik it’s pretty new, but how does it compare with Skia List that was announced not too long ago?

I haven't tested it, but could be an interesting comparison! Looks like Skia List would require big architecture changes to render items with skia instead of regular RN components? But I could see how it could potentially be faster to fully control all rendering...

@arnabxd.bsky.social

such perf diff while staying 100%JS is awesome

Any benchmarks on how this compares for example to @shopify/flash-list?

There's an example app in the repo which is what I recorded for that video. I'll work on making a good benchmark. From what I can tell it seems faster though.