Context idea - fevr 08.08.2016

Idee su come gestire l'ereditarietà del context, con la possibilità di fare modifiche da un certo punto della app in poi

Matteo Ronchi [10:16 AM]
@gianmarcotoso @michele @lucacolonnellocrweb e chiunque altro abbia input utili, ho una domanda per voi: Supponete di avere un manager/oggetto che ha dei valori che sono esposti via context ai children. Ma vorreste che alcuni rami usassero delle diverse configurazioni di valori. Ovviamente se ogni componente che usa questi valori ha nozione della chiave che deve chiedere all’oggetto nel context funziona tutto ma supponiamo che io volessi definire solo nel nodo ​X​ un nuovo set di valori e imporre a tutti i children/descendant questo set di valori ma senza passare una chiave esplicita ad ogni componente descendant… L’uso del context è opzionale se ci sono altri approcci che funzionano

TL,DR; per riassumere la radice ha 4 figli e 3 ricevono il colore rosso, ma uno e tutti is uoi children voglio ricevano blue definendolo solo in quel nodo padre di quel ramo

Michele Bertoli [10:20 AM]
bhe' il context funziona gia' cosi' nel senso di sovrascrivere i valori per i figli

Matteo Ronchi [10:21 AM]
si ma è globale no? cioè se sovrascrivo anche gli altri rami ricevono la modifica o clona ad ogni step (ammetto che non ho verificato) ma mi sembra molto costoso in termini di risorse clonare il context... anche lo facesse solo shallow

Luca Colonnello [10:23 AM]
ho capito al di là del modo, il context ha un problema a riguardo il figlio deve definire cosa vuole che i suoi figli vedano quindi fondamentalmente per come funziona ora con l’attuale context di react penso ci sia troppo effort da distribuire se invece creassi un container?

Matteo Ronchi [10:24 AM]
aspe il context fa quello che mi serve

Luca Colonnello [10:24 AM]
certo

Matteo Ronchi [10:24 AM]
la radice definisce nel context color e tutta l’app li riceve

Luca Colonnello [10:24 AM]
si

Matteo Ronchi [10:24 AM]
se poi un nodo aggiunge altri valori solo i suoi figli li vedranno (edited)

Luca Colonnello [10:24 AM]
certo

Michele Bertoli [10:24 AM]
http://www.react.run/rJ4F2T-t/2 (edited)

Matteo Ronchi [10:25 AM]
ma color lo vedranno sempre

Luca Colonnello [10:26 AM]
ma tu vuoi che color sia diverso solo da un certo nodo in poi e non vuoi specificarlo in quel nodo ma nel padre di tutti giusto?

Michele Bertoli [10:26 AM]

e non vuoi specificarlo in quel nodo ma nel padre di tutti ah ok non avevo capito

Matteo Ronchi [10:26 AM]
@michele si l’idea è quella immaginatevi lo scenario parliamo di un theme-manager per esempio anche se si può applicare a tanti casi (edited) l’app usa il tema white ma voglio che una modale e tutto il suo contenuto usi il tema red però non tutti i nodi della modale sono consapevoli del theme-manager quindi non posso semplicemente passare dalla modale ai figli che il tema è red e cmq passare la prop esplicitamente non mi piace (edited) l’esempio di Michele è nella direzione che desidero ora devo vedere se funziona anche con oggetti e non solo plain props però questo espone il fatto che il context viene ricalcolato potenzialmente ad ogni render e non mi piace molto @michele: fighissimo react.run :slightly_smiling_face:

Michele Bertoli [10:29 AM]
http://www.react.run/rJ4F2T-t/3 (edited) funziona anche con oggetti

Matteo Ronchi [10:30 AM]
@michele quindi ogni ramo può sovrascrivere valori senza impatatre gli altri rami (edited) questo non lo sapevo

Michele Bertoli [10:30 AM]
@cef62: yep l'ho scoperto qui: https://twitter.com/ryanflorence/status/717597674040467456 Ryan Florence @ryanflorence @MicheleBertoli cool, but I think you are now limited to a single Provider in the app, no? The second you provide twice it shadows __data. TwitterApril 6th at 8:19 AM

Matteo Ronchi [10:33 AM]
figo @michele!

Luca Colonnello [10:30 AM]
ok allora io ti prppongo questo:
crei un themeManager locale o meglio un themeManager globale che in pattern factory possa essere ricreato a partire dall’oggetto base con config differenti

Matteo Ronchi [10:31 AM]
@lucacolonnellocrweb: una cosa, io non posso sapere sempre che c’è un override eslicito mi spiego la dialog che usa red contiene altri container e alcuni dei loro children accedono al theme mangare, per fare override dovrebbero essere consapevoli del cambio di tema quindi deov cmq usare il context

Luca Colonnello [10:32 AM]
no beh certo ma se il themeManager è un istanza inserita nel context che tutti usano e da cui recuperano variabili tipo il color basta solo reistanziare il theme manager con config differenti nel nodo dal quale vuoi si applichi il tema red e tutti i figli lo useranno indipendentemente da quello che il padre ha impostato sbaglio?

Matteo Ronchi [10:33 AM]
mmmm io mi immagino (visto che michele ha sdoganato l’override x nodi) che la radice inietta un unico them manager nell'app e ha un default theme

Luca Colonnello [10:33 AM]
si esatto

Matteo Ronchi [10:34 AM]
poi il nodo dialog modifica il valore del theme da white a red

Luca Colonnello [10:34 AM]
esatto quello intendevo

Matteo Ronchi [10:34 AM]
e tutti i suoi figli, che accedono all’unico theme manager

Luca Colonnello [10:34 AM]
forse mi sono spiegato male

Matteo Ronchi [10:34 AM]
useranno red

Luca Colonnello [10:34 AM]
il problema è che devi creare un nuovo theme manager perchè se no le modifiche hanno effetti anche sui padri quindi il figlio dovrebbe fare tipo

Matteo Ronchi [10:34 AM]
no non è vero, basta che il them manager supporti + temi e tu gli chiedi il tema tramite la chiave

roberto diana [10:35 AM]
... of topic ... ma il context non verrà abbandonato in futuro ? ..

Matteo Ronchi [10:35 AM]
abbandonato difficilmente potrebbero cambiare le API se tolgono la DI in react perdono accesso a tutte le cose fighe che si stanno producendo

Luca Colonnello [10:35 AM]

    class First extends React.Component {
        getChildContext() {
            return { themeManager: this.context.themeManager.clone({
                // settings
                theme: 'red',
            }) }
        }
        render() {
            return <AnotherChild />
        }
    }

Matteo Ronchi [10:35 AM]
ah ok luca in realtà preferisco una singola istanza che tiene una mappa di temi e cambiare solo la chiave attiva del tema però il risultato è simile Figata cmq grazie a entrambi!

Luca Colonnello [10:36 AM]
però così facendo vuol dire che i figli devono sapere che tema richiedere al themeManager

Matteo Ronchi [10:36 AM]
questo mi apre delle possibilità molto fighe sul progetto che sto sviluppando (edited)

Luca Colonnello [10:36 AM]
come dicevo io è implicito per i figli (edited)

Matteo Ronchi [10:37 AM]
vero luca ma se i figli devono solo fare: const themmanager = this.context.thememanager(this.context.theme) è un male minore però si la tua soluzione risulta più pulita in realtà mi preoccupa poco la differenza perchè sarà tutto astratto in un HoC quello che vorrei evitare è di avere più di un istanza del theme manager ci lavoro su cmq poi vi faccio sapere!

Luca Colonnello [10:39 AM]
un altra soluzione potrebbe essere utilizzare una prop

Matteo Ronchi [10:40 AM]
no non è sostenibile non tutti i componenti sono a conoscenza del theme-manager

Luca Colonnello [10:40 AM]
ma la prop serve solo a definire quale tema vuoi da li in poi, però per propagare la cosa ai figli deve essere implicita secondo me...

Matteo Ronchi [10:40 AM]
intendo che se la dialog riceve come prop il tema red

Luca Colonnello [10:40 AM]
si usando il context potrebbe andare ma ovviamente hai il problema al contrario la variabile theme nel context diventa una dipendenza esplicita può fungere lo stesso però

Matteo Ronchi [10:41 AM]
lo dovrebbe passare esplicitamente a tutti i children, ma cosa succede se un children non sa cosa farsene della prop them e non la passa au suo descendant? (edited) beh si un tradeof c’è sempre

Luca Colonnello [10:41 AM]
no infatti intendevo di passarlo solo al primo padre che deve sovrascrivere però facendo così stai generando un istanza del theme manager ad ogni componente che lo usa

Matteo Ronchi [10:42 AM]
esatto vorrei evitarlo

Luca Colonnello [10:42 AM]
invece mettendolo nel context solo chi lo cambia lo sostituisce però una soluzione potrebbe essere non reinstanziare ma cambiare a runtime il tema dal padre al figlio senza riprodurre oggetti un po come immutable (edited) immagina che il themeManager non è un instanza pura ma una rappresentazione dei metodi pubblici quindi un oggetto plain

Matteo Ronchi [10:44 AM]
yep

Luca Colonnello [10:44 AM]
che all’interno si riferisce alla vera istanza di themeManager ma usa le config dell’oggetto per lavorare tipo red:mainColor è il modo in cui recuperi il colore ma red non lo usano i componenti (edited) usano solo mainColor chiamando funzioni di un oggetto plain che conosce sia red che il themeManager e in reflection chiama themeManager.get(${this.theme}:${propName}) quindi themeManager pubblico è una factory di oggetti di questo tipo e così il padre può semplicemente fare come ti dicevo ma non ricrea tutto ma solo il POJO pubblico che ha 3 cose o forse bastano 2 il get e il tema attuale

Matteo Ronchi [10:46 AM]
si può funzionare, molto dipende da come sarà internamente il themmanager (edited) ma l’idea è questa la API sono 3 imho: get, set, theme in realtà 4 ci vuole anche register per aggiungere nuovi temi

Luca Colonnello [10:48 AM]
esatto così da quello ne crei altri nei figli che vogliono sovrascrivere

Matteo Ronchi [10:48 AM]
sarebbe figo farlo senza neanche il context

Luca Colonnello [10:49 AM]
e questo potrebbe non essere un themeManager ma un wrapper per la DI con il context

Matteo Ronchi [10:49 AM]
ma vorrebbe dire creare un meccanismo di DI ad-hoc

Luca Colonnello [10:49 AM]
una roba tipo Pimple in PHP ma per React no no sempre con il context serve solo a definire questo meccanismo dinamico ma pulito

Matteo Ronchi [10:49 AM]

e questo potrebbe non essere un themeManager ma un wrapper per la DI con il context spiega melgio (edited)

Luca Colonnello [10:50 AM]
se io genero un wrapper che ingloba un oggetto, e gli passo una factory con impostazioni (utile all’inizio e a fare anche il register) può wrappare qualsiasi oggetto le api le definisco io lui definisce il meccanismo se io creo get e gli faccio fare quello che dicevamo è tutto flessibile e generico e va bene per qualunque cosa lui definisce solo l’interfaccia pubblica che però è risultato di una factory che crei tu quindi può fare qualunque cose secondo questo meccanismo anche un sistema di settaggi differente da un tema o di oggetti veri e propri derivati da classi

Matteo Ronchi [10:52 AM]
gotcha, si infatti il theme manager era solol’esempio più facile su cui discutere (edited)

Luca Colonnello [10:53 AM]
:slightly_smiling_face:

Matteo Ronchi [10:54 AM]
poi non so quanto abbia senso fare un sistema generico (nel mio caso attuale) ma vedremo… sett prox ci lavoro attivamente :slightly_smiling_face: grazie a entrambi ragazzi!

Luca Colonnello [10:57 AM]
:slightly_smiling_face:

roberto diana [10:57 AM]
raga ma che ce relazione fra context e DI ? o forse no c'è relazione ... ? (edited)

Matteo Ronchi [10:58 AM]
il context è l’unico meccanismo nativo che React offre per avere qualcosa di simile alla DI concettualmente parlando non è la stessa cosa ma offre la possibilità di accedere a dati non forniti direttamente dal parent container

roberto diana [10:59 AM]
ah! ok non riuscivo a collegare con la DI (edited)

Matteo Ronchi [10:59 AM]
in angular tu inietti un servizio

roberto diana [10:59 AM]
in angular è chiarissimo in react meno (per me ... obv)

Matteo Ronchi [11:00 AM]
in react passi props, ma se devi passare un servzio ail pronipote dovresti passare il servizio anche al figlio e al nipote il context ti permette di passare al pronipote senza passare esplicitmaente tra i nodi intermedi

roberto diana [11:01 AM]
che comunque non è proprio DI ma ho capito meglio adesso :smile:

Matteo Ronchi [11:01 AM]
esatto :wink: React, a quanto mi risulta, non usa Reflection o altre tecniche per iniettare il context, semplicemente lo gestisce per te lungo l’albero di componenti

roberto diana [11:02 AM]
lo clona ? o usa reference o qualche meccanismo simile ?

Matteo Ronchi [11:04 AM]
se leggi il thread sopra ci sono gli esempi di michele che mostrano che ogni volta che un nodo definisce qualcosa nel context viene prodotto un nuovo context che mantiene relazione con ciò che è definito dai livelli superiori ma che permette un safe override da quel punto in poi per un dato ramo questo http://www.react.run/rJ4F2T-t/3

roberto diana [11:05 AM]
missato ora leggo grazie

Matteo Ronchi [11:05 AM]
:wink:


results matching ""

    No results matching ""