This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-12-02
Channels
- # adventofcode (5)
- # arachne (2)
- # bangalore-clj (1)
- # beginners (8)
- # boot (195)
- # cider (28)
- # cljs-dev (35)
- # cljsrn (4)
- # clojure (295)
- # clojure-brasil (5)
- # clojure-gamedev (2)
- # clojure-greece (2)
- # clojure-korea (13)
- # clojure-russia (60)
- # clojure-spec (58)
- # clojure-uk (92)
- # clojurescript (31)
- # clojurex (4)
- # css (1)
- # cursive (13)
- # datomic (40)
- # devcards (2)
- # emacs (17)
- # events (1)
- # flambo (3)
- # garden (9)
- # hoplon (31)
- # jobs (3)
- # klipse (1)
- # lein-figwheel (1)
- # london-clojurians (1)
- # luminus (2)
- # mount (36)
- # off-topic (13)
- # onyx (8)
- # pamela (1)
- # pedestal (1)
- # planck (3)
- # proto-repl (16)
- # protorepl (11)
- # re-frame (78)
- # reagent (4)
- # rethinkdb (6)
- # ring-swagger (1)
- # specter (8)
- # untangled (10)
- # vim (1)
@sandbags hi, where are you looking the homepage? https://github.com/flexsurfer/re-frisk here is 0.3.1 the latest version with the fixed scroll, but i would recommended using external window debugger, because more features, i want to get rid of panel, it's only need for clojure/conj 🙂
@andre sorry i think i must have added the dependency earlier and only used it yesterday, then thought i’d added it yesterday when i ran lein ancient
When you say “use external debugger” I am not sure if you mean “use something else, not re-frisk” or “use the re-frisk in its own window” option
@andre yep.. i have used the window and it’s cool, getting the events was a nice bonus
@andre thank you for making re-frisk … it’s handily replaced my crappy “debug view” in the app
glad to hear , thank you, in plan i whant to add re-frame effects and subscribtions lists
@andre one suggestion though, if you’ve a moment, if you can replace [Object Object]
(I’m going from memory here) with something shorter it would help
I have some cases where i have maps with a lot of keys that are Clojure records that end up being represented [Object Object]
and it takes up a lot of space visually when some short-hand would be better
It’s a pity I can’t make those records more useful… they are basically wrappers for an id
@andre i can think of one instance in which the panel approach could be very useful: if you could “focus” the panel on a specific sub-tree of db
and turn it into a kind of “watch"
then you just have the value you are interested in, right in your visual focus where you want it
@sandbags so , there are alot of data that changing, but you want only watch some current value?
for example i track both date and a day delta. When I was testing the code that updated them together i would have loved to be able to focus on the matching part(s) of the data structure
(re-frisk.core/add-data :mywatcher (reagent.ratom/make-reaction (fn [](:data @re-frame.db/app-db))))
you can run this in the REPL, this is workaround for “focus” the panel on a specific sub-treeFor example:
(fn [foo]
(reagent/create-class
{:component-did-mount
#(side-effect! foo)
:reagent-render (fn [foo] [:div#foo])})
I am having a problem and I think I know why but I’m not sure what to do about it. Within my app-state I have a map one of whose values refers to a component that will represent the “main view”. Events can change the main view by updating this. What I used to do was use a keyword and I had a case statement like (let [view (…)] (case view :foo [foo/foo-view] :bar [bar/bar-view]))
and so on (in reality a little more complex but that was the essence of it). I didn’t like that so I decided what if I just stuff the symbol for the component into the db, now I can just do (let [view (…)] [view])
which works except that when I update the view code the view is reloaded but I am still looking at the old component output. I now think it may be related to how code re-loading works and having the symbol in a data-structure I am some-how hanging on to the ‘old' component function whereas referring to the symbol directly yields the output of the updated component function. Maybe... Anyone know for sure what is going on here? And can anyone suggest how I can dynamically switch views from the database without hard coding a lot of symbol lookup? Was thinking maybe of using :foo/foo-view
and trying to turn that into a symbol at run-time. Would love to hear, how are other people solving this problem?
I’m wondering if the “resolve by name” approach is feasible in ClojureScript since it doesn’t have ns-resolve
and I see suggestions the Closure compilers optimisations make it unworkable.
@sandbags
I think what you want is store the symbol in the app-db like 'foo/fooview
(note the quote) and when you take it out, resolve
that symbol to the actual view
hrmmm if i can’t use resolve i can’t use the symbol unless I am missing something obvious
i’m having a brain fade moment… how do I turn ‘foo/foo-view
into foo/foo-view
… it’s via ns-resolve
right?
@sandbags you can use a multimethod instead of case ... lets you declare the multimethod near where it is used, and define the render implementations wherever they belong
Ah so you mean I define a multi like main-view
and a set of methods for each component view and use the keyword to switch on method
@sandbags exactly - here's a compact example - https://www.refheap.com/124078
i would only use form-1 components with a multi-method though - i think you might find weirdness with form-2 or form-3 components
remember that in re-frame 0.8 and above you can use subs efficiently in form-1 components... i think form-2 components are kinda obsolete now
@sandbags have a look down the bottom of https://github.com/Day8/re-frame/issues/218 "It is now officially guaranteed that you can use subscribe in a Form-1 Reagent view function. This guarantee will officially be a part of the 0.9.0 release, but it already works in v0.8.0."
was the solution to using subs in form-1 simply to move them into the component function? Or was there other work you needed to do? (Essentially I am asking if I need to go look up where this was described or if the easy path is the right one)
@mccraigmccraig many thanks, again !
how would you choose between "passing down" data obtained from a subscription to a component and subscribing to the data in an underlying component directly? are there any non-obvious considerations?
I usually have the components subscribe directly because it could re-render seperately, if you pass data down, the whole thing would always re-render
on the other hand, this makes your components harder to decouple from your app, you'll need to write a stub for the subscribe
/`dispatch` functions to test your component seperately.
Man, whoever gets these online is fast! Here's my talk from the Conj, only 2 hours from completion to youtube https://youtu.be/cDzjlx6otCU