- Navios
- 30 de agosto de 2026 às 18:14 UTC
- Autor
- Kamo
- Enviar
- 9c8c502
A caixa de seleção ao lado de cada calendário foi vinculada a `calendar.isVisible` e sua no Change foi 'fetchEvents'. `isVisible` é enviado por EmailService e reposta por nada na plataforma — todas as 69 linhas activas em `user calendars' `is visible = true’ — e refetching eventos muda nenhum estado que a caixa lê. Então... Reagir re-renderizou a caixa com o `checked` que já tinha e o clique Desapareceu. Sempre verificado, nunca incontrolável, em cada org: exatamente o que foi reportado. A página já tinha o estado que este controle queria. `selecionadoCalendar Filtros de IDs `filteredEvents`, e a lista de seleção idêntica dentro da CalendarSearchBar comuta corretamente. A barra lateral simplesmente nunca foi ligada a ela, então dois controles sobre um conceito discordava e o mais óbvio era o morto. Desmarcar o último calendário teve um segundo bug esperando atrás do primeiro. A filtro foi guardado com `selectedCalendarIds.length > 0`, então uma seleção vazia caiu do filtro completamente e cada evento voltou — o membro limpa A lista e a grelha enchem-se. Vazio não poderia significar "nenhum deles" enquanto ele também significa "ainda não carregado", então esses dois estados agora são valores separados, `[]` e Null, em... O que significa que o inicializador teve de parar de usar "a selecção está vazia" para decidir ele nunca tinha executado, ou um calendário all-un-checked iria verificar-se novamente no próximo renderização da lista. Ele agora rastreia os IDs do calendário que viu: um calendário o página nunca mostrou começa visível, e um membro não verificado permanece dessa forma. Isso também corrige os eventos de um calendário recém-criado sendo filtrados para fora da grade Foi criado de onde. A seleção permanece estado de visualização ao invés de uma preferência salva, que é o que o A barra de busca já era. Persistindo que precisa de uma coluna algo Na verdade, escreve.