This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-04-23
Channels
- # announcements (2)
- # beginners (82)
- # calva (13)
- # cider (12)
- # clara (4)
- # cljdoc (22)
- # clojure (89)
- # clojure-dev (23)
- # clojure-europe (16)
- # clojure-italy (39)
- # clojure-nl (8)
- # clojure-spec (28)
- # clojure-uk (36)
- # clojurescript (40)
- # cursive (10)
- # data-science (1)
- # datomic (27)
- # devcards (4)
- # emacs (1)
- # fulcro (25)
- # jobs (1)
- # jobs-discuss (3)
- # kaocha (5)
- # luminus (1)
- # nrepl (68)
- # off-topic (64)
- # pedestal (23)
- # planck (1)
- # quil (4)
- # re-frame (6)
- # reitit (5)
- # remote-jobs (4)
- # shadow-cljs (16)
- # spacemacs (11)
- # testing (1)
Namaste
Sondaggino - cosa usate: Component, Mount, System, Integrant o nessuno dei precedenti
Usiamo anche noi Mount, ma non ne sono soddisfatto al 100%
E' bello che lasci risolvere le dipendenze da Clojure, ma ogni tanto sento la mancanza di una mappa esplicita che mi dica chi dipende da cosa
(sarà il mio passato da Pythonista, "Explicit is better than implicit")
Sicuro, ma non è la mia idea di explicit 😅
Component allora fa piu' al caso tuo. A me non piace molto l'implementazione come record
Stavo valutanto Integrant a dire il vero
Argh, dependency graphs? Mi ricorda dei bei tempi di Spring e dependency inversion in generale. Siete tornati agli oggetti?
Che c'entrano gli oggetti?
Non è che tutto ciò che contiene uno stato sia necessariamente un oggetto
@reborg dici che sia meglio un global state come una volta?
Che sappia io, tutti i component frameworks hanno da qualche parte un global state (che poi puo’ piu’ o meno avere states satelliti in altri namespaces). Mi piace usare components (per REPL dev/testing), ma sto ben alla larga da qualunque offerta di dependency injection (tipo, dimmi cosa component-A vuole e il framework te lo fa arrivare). Quello e’ il punto in cui per capire cosa fa l’app devo basarmi su una configurazione “esterna” e seguire 2 flussi invece di 1: codice e dependency graph. Ma non vedo il vantaggio di fare una cosa del genere.
Quindi quello che ho nelle mie app e’ tipo: (ns2 (:require [ns1.state :refer [system]])) (db/query system/conn "select * from blah")
Capisco ma non concordo
@mdallastella contento di saperne di piu’
@reborg preferisco tenere lo stato di un componente all'interno del namespace a cui serve e forse non sono abbastanza skillato da usare tecniche differenti tra dev/testing e production. Per quando riguarda la dependency injection, siamo ben lontani da Spring o da Guice: Component, Mount & co non fanno nulla di magico in questo senso.
Nel caso di Integrant (come in Component) le dipendenze (quindi il dependency graph) devono essere esplicitate
Non è il caso di Mount, che, lasciando la risoluzione ai require di Clojure può portare a dei loop nelle dipendenze
E a dire la verità, ogni tanto il REPL development frega in qualche caso
Un component framework deve darmi come minimo: 1. un (reset)
per il REPL 2. non costringermi ad esplicitare dipendenze. Alcuni dei tool citati penso siano ok per entrambe i punti.
Certo. Mount da questo punto di vista è quello che si avvicina di più a quello che chiedi.
Se quindi il component framework non e’ contagioso (cioe’ un component e’ tale solo se e’ stateful e non perche’ e’ client di un component) il “dependency graph” di una app arbitrariamente complessa non dovrebbe mai superare gli 8-10 nodi.
@mdallastella noi in Juxt usiamo integrant con edge che è una in house made library che offre production ready code.. la usiamo per tutti i nostri progetti in production .. se vuoi dagli una occhiata .. è open source -> github/juxt/edge
Sì, l'avevo notata, grazie mille! ☺️
Anche io uso integrant parecchio ed è ottimo
La libreria component non mi piace molto ed è troppo invasiva Imho ma con integrant ci troviamo molto bene
Non c'è proprio niente di magico