Mamy kod tak:Czy w sieci można obsługiwać cykle obsługi reaktywnego banana?
guiState :: Discrete GuiState
guiState = stepperD (GuiState []) $
union (mkGuiState <$> changes model) evtAutoLayout
evtAutoLayout :: Event GuiState
evtAutoLayout = fmap fromJust . filterE isJust . fmap autoLayout $ changes guiState
Widać, że evtAutoLayout zasila guiState która doprowadza do evtAutoLayout - więc jest tam cykl. To jest celowe. Układ Auto dostosowuje stan GUI, aż osiągnie równowagę, a następnie zwraca Nothing, a więc powinien zatrzymać pętlę. Nowa zmiana modelu może oczywiście ponownie ją uruchomić.
Po umieszczeniu tego razem uruchamiamy nieskończoną pętlę w wywołaniu funkcji kompilacji . Nawet jeśli autoLayout = Nothing, nadal powoduje przepełnienie stosu podczas kompilacji.
Gdybym usunąć wywołanie związkową w guiState i usunąć evtAutoLayout z zdjęcie ...
guiState :: Discrete GuiState
guiState = stepperD (GuiState []) $ mkGuiState <$> changes model
to działa dobrze.
Wszelkie sugestie?
Odkąd powiedziałem, że mogę poprosić o wyjaśnienia/przykłady ... w twoim filterRising, po co jest pierwszy parametr? Jeśli to tylko konwersja zdarzenia do zdarzenia, dlaczego ma 2 parametry? A jak wykorzystałbyś filterRising? Dzięki! – mentics
@taotree: Ah, pierwszy parametr był tylko pewnego rodzaju wartością początkową. Teraz zmieniłem przykład, aby pasował do opisu. Używanie funkcji 'filterRising' jest proste: pobiera strumień zdarzeń jako argument i zwraca w rezultacie nowy strumień zdarzeń, dzięki czemu można go zastosować do wybranego strumienia zdarzeń i uzyskać nowy. –