Sto facendo eventi giusto?

Question

Sto facendo eventi giusto?

#1 da (3 voti)
#2 da (1 voti)

3

Il mio problema è con JavaScript nel browser, ma suppongo che potrebbe applicarsi a qualsiasi ambiente basato su eventi.

Ho codificato un widget nella mia app. Il widget consente all'utente di selezionare un oggetto utilizzando 3 diversi sotto-widget (tabella, mappa e galleria). I sotto-widget visualizzano gli stessi elementi e una selezione può essere fatta da qualsiasi sotto-widget che l'utente preferisce usare. Ogni volta che una selezione viene effettuata dall'utente o impostata nel codice, l'evento "selezione-modificata" viene attivato dal sotto-widget. Il widget principale ascolta questi eventi "selezionati-modificati".

Questo ha funzionato bene fino a quando ho iniziato ad andare oltre con il progetto e ho realizzato che dovevo regolare la selezione negli altri 2 widget quando la selezione cambia (se l'utente seleziona un elemento sulla mappa, dovrebbe evidenziare lo stesso elemento nel tavolo e nella galleria). Il problema è che quando imposto la selezione negli altri 2 sub-widget, attivano l'evento "selection-changed" e questo diventa piuttosto ricorsivo. Questo succede anche quando ho bisogno di cancellare la selezione in tutti i sotto-widget (ottengo 3 eventi "selezionati-modificati" con gli stessi dati vuoti). Ciò porta a numerose chiamate ridondanti fatte per risorse esterne e mi dà la sensazione che in futuro porterà a ulteriori problemi.

Quindi la mia domanda è che sto facendo degli eventi, giusto? La risposta è ovviamente "no" perché mi sono coccolato in un sottaceto così presto, ma mi chiedo come le altre persone usino gli eventi senza entrare in questi problemi - che tipo di architettura sarebbe meglio in questa situazione?

Forse potrei avere un modo di impostare e cancellare le selezioni nei sub-widget che non vanno a fuoco per l'evento ma questo sembra un hack e potrebbe finire in conflitto con il framework che sto usando per gestire il mio views / modelli.

architecture event-programming

posta OrganicPanda 13.08.2013 - 15:43

fonte

2 risposte

1

Questo è un problema comune con un sistema di eventi. C'è una principale autorità centrale, che spinge gli eventi da e verso gli ascoltatori. È piuttosto grezzo, ma lavorabile.

C'è una piccola presa qui. Il sistema diventa presto più complicato e la propagazione degli eventi è più o meno opaca. È difficile determinare quale sia il sistema in realtà. Anche gli effetti indesiderati possono insinuarsi.

Ci sono già due soluzioni date, che sono soluzioni eccellenti, ma voglio anche dare una soluzione, che è un raffinamento sul modello di evento.

Programmazione reattiva

Se prendi un sistema di eventi grezzo e lo suddividi in parti più piccole, vedrai che ci sono diverse funzionalità, che sembrano essere condivise:

Filtraggio degli eventi
Spingendo gli eventi nello stream di eventi (che è una fonte di eventi)
Agire sul flusso di eventi. (che è un afflusso di eventi)
Manipolazione degli eventi nello stream (ad es. mappatura su di essi)

Nella programmazione reattiva questi componenti sono separati e come puoi vedere, è possibile costruire il modello grezzo da questo. L'elemento chiave è che si separa l'input dall'output.

Con questi componenti puoi creare una rete e indirizzare esplicitamente i tuoi eventi attraverso la tua applicazione. Ciò rende il funzionamento del sistema più trasparente e aggiunge anche molta flessibilità. La cosa interessante di questo è che puoi unificare gli eventi dai callback al sistema.

Una rete appare in genere in questo modo:

clickbutton -> some switching -> change picture 
app1-change --/  /          \----> stopclock
clock_tick -----/            \----> start clock

Un interessante concetto di programmazione reattiva è il seguente sito: funzionale reattivo-programmazione-con-pancetta-js /

Nella programmazione reattiva funzionale, ci sono due cose che possono propagarsi attraverso la rete. Behaviors, che sono segnali continui. Pensa al movimento del mouse dell'utente. E gli eventi, quali segnali discreti. Questo è un po 'più teorico di acque più profonde rispetto alla normale programmazione reattiva.

risposta data 14.08.2013 - 23:57

fonte

Leggi altre domande sui tag architecture event-programming

Semantic versioning e suddivisione di una libreria, fornendo una build in bundle Spiegazione della definizione di ereditarietà dell'interfaccia come descritto nel libro GoF

score 3 · Accepted Answer

La mia soluzione preferita per questo problema di ricorsione (ce l'ho molto) è di avere un controllo di ogni azione per vedere se ha davvero fatto qualcosa prima di attivare l'azione successiva. In questo caso, la prima subwidget cambia e notifica la superwidget, che, notando che la sua condizione (la superwidget) è davvero cambiata, dice agli altri due subwidgets di cambiare. Ogni widget che fa deve cambiare (alcuni potrebbero già essere impostati correttamente) lo fa e notifica la superwidget. Tuttavia , a questo punto superwidget nota che le notifiche non hanno cambiato il suo stato, quindi non dice a nessuno di fare nulla e la ricorsione si arresta.

Altrimenti uso la soluzione a due eventi di Dan Pichelman. È meno elegante, ma a volte più veloce. Ma di solito preferisco la soluzione elegante, funziona anche in situazioni davvero complicate.