Closed theastrogoth closed 8 months ago
Something about this breaks iOS Safari compatibility, but I'm not yet sure what
Thoughts on moving all the raider searching logic into a dedicated modal? Doesn't necessarily need to replace what's already here since the current setup allows users to quickly add a pokemon. Just adding an extra button that opens the modal.
Possible mockup of a modal. This is quite a bit more complicated than the current implementation but it can offer a more user friendly interface.
That looks a lot cleaner! I like this a lot; more user friendly, and it would also add another layer of interaction before fetching the large files for species lookup.
Having selectable builds here is a neat idea, too.
I was planning on trying out table virtualization with react-virtuoso to avoid the long render time for large lists of results, so I combined all results into a single table before realizing that multiple sticky headers probably won't work in a virtualized table.
Would multiple virtualized, scrollable tables be too much? The debouncing has already helped quite a bit, so it might not be worth it.
Might be okay. One benefit of having multiple tables is that you don't have to scroll past everything else to get to the moves section (can't think of a scenario where this would actually be a significant issue though). Multiple tables might also make it easier to create a clear separation between the Pokemon results and the filter results.
Added some basic row sorting, feel free to change as needed. With sorting, it can be helpful to list all Pokemon instead of no Pokemon if no tags are selected
Need to find a good way to indicate which column is being sorted and which direction, maybe an up/down chevron in the column header button.
Possible improvements/features
I couldn't figure out dynamic sizing for virtualized containers, so I went with putting the results GroupedVirtuoso
for virtualization. One downside of this compared to using a table is that each cell had to be given a fixed width to keep things uniform, so the table currently has a fixed width overall, which doesn't look great on large screens.
Height of the table is a set percentage of the viewport height, which isn't perfect either, but at least performance seems a lot better.
Yea I think it still looks fine on desktop.
I deployed this branch to see if the page will load on my phone, but no luck.
When I deployed again after commenting out the <PokemonLookup>
component in BuildControls.tsx
, things work again. So at least the issue isn't something to do with allSpecies
and allMoves
elsewhere - it's an issue introduced by the new component.
Any chance you could check to see what error is getting thrown? I don't think I can do it without a Mac
Add filters to the Pokemon Autocomplete field. Filters can be the following:
There's not currently any limit on the number of filters that can be applied.
Filters other than custom ones should work regardless of the selected language. Custom filters probably only work properly for a single language.
To search through movesets, a large-ish (5 mb) file is downloaded the first time an Autocomplete is focused on. This might be somewhat slow for those with a bad internet connection. The good news is that it won't be downloaded if all a user does is view a saved strat.
closes #107