This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-05-31
Channels
- # admin-announcements (4)
- # alda (3)
- # aws (1)
- # beginners (2)
- # boot (33)
- # braid-chat (4)
- # braveandtrue (20)
- # cider (52)
- # cljs-dev (13)
- # cljsrn (55)
- # clojure (111)
- # clojure-belgium (4)
- # clojure-brasil (6)
- # clojure-dusseldorf (1)
- # clojure-greece (116)
- # clojure-mexico (1)
- # clojure-nl (3)
- # clojure-russia (56)
- # clojure-spec (72)
- # clojure-uk (13)
- # clojurescript (66)
- # community-development (2)
- # component (24)
- # core-async (1)
- # cursive (19)
- # datomic (27)
- # devcards (5)
- # emacs (1)
- # funcool (34)
- # hoplon (313)
- # jobs (1)
- # lein-figwheel (11)
- # luminus (5)
- # mount (30)
- # off-topic (63)
- # om (375)
- # onyx (67)
- # perun (8)
- # proton (1)
- # reagent (4)
- # rum (1)
- # specter (55)
- # spirituality-ethics (7)
- # test-check (2)
- # untangled (34)
- # yada (20)
@micha: https://github.com/adzerk-oss/boot-cljs/pull/119 can I CC you on this? You know a little more about boot's "big plans" for it.
@martinklepsch: I really appreciate your input. ❤️
i think we should follow the protocol of using the env at task construction time for pods that will be spawned later
@micha I think that's a very reasonable default but I think it's also a hindering constraint when creating more complex setups (edge/lambone)
Yeah sometimes you really want to specify deps at task runtime..I remember the need
And I remember I read Deraen solution and thought it would be nice if pods had "settable" dependencies
Yes well if it's going to be a dynamic var it is already thread bound
@richiardiandrea: when you say at runtime, do you really mean at runtime or more like "different than the main env"
But I need to fetch an example first s that it is clear what I am talking about
And I am on mobile now so cannot really do it, I will just follow the discussion ;)
maybe @richiardiandrea and @dominicm can make a wiki page with the kind of things they found lacking and then that can be used to come up with a solution?
Yeah, and some descriptions of use cases where separate frontend / backend dependencies are needed could be helpful
@juhoteperi: The ability to have different core.async libs is neat (or any other cljc project). Also, not "polluting" your java project with sub-dependencies of the clojurescript libraries is nice. It's a bit of a "purist" view on isolation from each other.
Well the apps I build are so tied together that there is no really isolation between backend and frontend
Different core.async versions sound bad as there might be some code which uses core.async and is used on both back and front
So the descriptions of use cases are necessary for me to understand what you want to do, otherwise I'll presume other people build same kind of apps as I do 😄
@juhoteperi: More than fair 😛. I think it's useful to have control over what is both, and what is either. > Different core.async versions sound bad as there might be some code which uses core.async and is used on both back and front Without being overly specific: You may not have time to upgrade frontend / something is breaking in your hacks from an older version / etc.
It's more defensive programming in my mindset, than a strong solution. Boot makes that kind of isolation fairly easy to achieve so it seems like a perfect match 🙂
Agree and Lambone (following edge) tries to separate f/b but still keep the same JVM...the result is great I think (of course). The biggest limitation was that I could not inject my own custom deps in tasks like cljs
because they are creating pods at task creation time
So I have to call set-env!
at my task creation time
It would be great if I could just pass my deps to the task and cljs
would then pass them to the pod without fetching them from get-env
I hope is clear, I can paste a code sample