can't search for some genera or families in 'choose a genus/family' bar

[tmesaglio]

1. Set coordinates to -30.384972, 153.011733, choose a 50 km radius and search for all genera
2. Returns thousands of records, and if you search for the genus Sparganium within the species records tab search bar, you get one result:
   
3. Now click in the 'choose a genus' bar on the left, and start to type in Sparganium
4. There is no match, even though it's clearly a legitimate choice
5. This is almost certainly related to the issue at genus and family dropdowns don't allow scrolling through all entities for Plantae parquet #60

[wcornwell]

tough one. any idea if this missing genera thing is only for the select a lat/long? Or does it should up for the pre-loaded kml's also?

[tmesaglio]

pre-loaded KMLs too

[wcornwell]

what's an example?

[wcornwell]

i think i found a bug in the circle code that's not updating the genus/family lists as you move around and you get the last preloaded kml genus list (e.g. still getting the fowler genus list), but if it's in the preloaded kml's too then there is a deeper issues.

[tmesaglio]

Sparganium is unsearchable for all of them

[wcornwell]

we have to do some kind of spatial subset of genera or else it crashes the whole app because of allowing too many choices...

[wcornwell]

not working perfectly yet, but can find Sparganium now:

[tmesaglio]

I don't know if this solves the problem at all, but what if the only option in the dropdown menu was 'all', and then you could also search in it to retrieve a single genus? Just remove all the other genera from being displayed, would that help? Same thing for family menu

[wcornwell]

not sure if it's possible within this https://selectize.dev/docs/usage. let's discuss at the next meeting

[wcornwell]

chatGPT's thoughts on this problem:

[wcornwell]

right now we're doing (4), and we definitely have the problem that the robot mentions at the end....

[tmesaglio]

when I just ran the app locally, this is now broken again. For some of the preloaded places, I can't search for any genera or families

[wcornwell]

arggg, it's fine on my mac, but i can get the bug on the windows machine...

[tmesaglio]

it's weird as well because I tested for one preloaded place, couldn't search for anthing -> swapped to another place, could search for a genus that I tested --> swapped back to the first place and that single genus was now on the list along with 'all'. So something convoluted going on

[wcornwell]

yup, i have the same--something not updating properly when you switch places.

[wcornwell]

The issue you're facing with updateSelectizeInput not producing any options because intersect_data() isn't done yet is likely a synchronization problem between reactive dependencies.

When a user event triggers changes, some reactive computations may not finish before others are executed, leading to the described behavior. Here's a solution using reactiveVal to ensure synchronization:

1. Introduce a Reactive Value: Use reactiveVal to hold the state for the select inputs. This ensures that updateSelectizeInput only updates once the required computations are done.

# Initialize a reactive value
data_ready <- reactiveVal(FALSE)

2. Update data_ready after intersect_data() computation: Within the reactive block for intersect_data(), set data_ready to TRUE once the computation finishes.

intersect_data <- reactive({
    #... your existing code ...

    # Set data_ready to true once the computation finishes
    data_ready(TRUE)
    return(data)
})

3. Observe data_ready and update inputs: Instead of directly observing the combined_input(), observe the data_ready value.

observe({
    if (data_ready()) {
        # Reset the reactive value
        data_ready(FALSE)
        
        updateSelectizeInput(
            session,
            "taxa_genus",
            selected = "All",
            choices = update_genus_choices(input$place),
            server = TRUE
        )
        
        updateSelectizeInput(
            session,
            "taxa_family",
            choices = update_family_choices(input$place),
            selected = "All",
            server = TRUE
        )
    }
})

This way, the input updates will only occur after intersect_data() has computed its result.

However, another way to handle this is by directly integrating the updateSelectizeInput within the intersect_data reactive, right after your data manipulations, ensuring that they're executed right after your data is ready. This might lead to a more synchronous behavior but could clutter your reactive definitions. The approach with reactiveVal is more modular and explicit about the synchronization step.

Lastly, ensure you don't have other reactivity chains that might cause premature triggers. The Shiny reactive system is quite powerful, but it's essential to be mindful of the order and dependencies between reactive elements.