This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (2)
- # beginners (20)
- # boot (139)
- # cider (6)
- # clara (1)
- # cljs-dev (7)
- # cljsrn (4)
- # clojure (160)
- # clojure-berlin (1)
- # clojure-canada (6)
- # clojure-gamedev (1)
- # clojure-japan (7)
- # clojure-russia (14)
- # clojure-spec (90)
- # clojure-uk (10)
- # clojurescript (73)
- # clojutre (1)
- # conf-proposals (8)
- # crypto (67)
- # cursive (9)
- # datomic (6)
- # editors-rus (1)
- # events (1)
- # figwheel (6)
- # funcool (2)
- # hoplon (19)
- # instaparse (37)
- # kekkonen (4)
- # lein-figwheel (2)
- # leiningen (5)
- # luminus (1)
- # off-topic (1)
- # om (10)
- # onyx (60)
- # protorepl (2)
- # re-frame (81)
- # reagent (10)
- # ring-swagger (15)
- # rum (6)
- # specter (17)
- # test-check (10)
- # uncomplicate (31)
- # untangled (12)
- # yada (6)
well, for a starter, look at https://github.com/Day8/re-frame/blob/master/examples/todomvc/src/todomvc/views.cljs#L53 and why not write
all-complete? @(subscribe [:all-complete?]) instead of
@all-complete? further down?
@michael.heuberger are you familiar with https://github.com/Day8/re-frame/wiki/Creating%20Reagent%20Components ?
If we dereffed the subscription in the let block outside of the inner function, the subscription would only update if the whole component was destroyed. Probably not what you want
@michael.heuberger In that case, I think you might need to go over the re-frame docs again, perhaps from this point on: https://github.com/Day8/re-frame#how-flow-happens-in-reagent
Oh, right. Are you saying that you want to ditch Form-2 and just go with Form-1 ?
@danielcompton why shouldn’t we use form 1 when using subscribers? it is possible
Interestingly enough, in v0.8.0 this may actually work (theory untested) because re-frame now has query de-duplication. The subscription you used last time will be the one you use this time. But this is an implementation detail at this point.
using v0.8 here … form-1 still not recommended in conjunction with subscribers? is there an example demonstrating this issue?
It did occur to me during the v0.8.0 release process that I should look more into this, but that thought got washed away with the need to get a release out the door.
thanks, that’s good to know. but for now, using re-frame v0.8, is this statement still valid? "you shouldn’t use a form-1 if you need a data subscription”?
So, final clarification. Using subscribe with Form-1: 1. Didn't really work <= 0.7.0 Because it caused a new subscription to be created on each rerender. 2. It now may work (as of v0.8.0) but it is still in the realm of implementation detail (subscriptions are now cached and de-duplicated) 3. It is something that may become "real" in a future release
I’m planning on a talk proposal about re-frame, but I’m a little stuck on direction right now. There are a few different places I could put the main focus - What is re-frame and how to use it from the perspective of a beginner. Doesn’t expect audience has ever built anything with React or Reagent, could possibly be targeted specifically at Clojure devs who have never built anything substantial in CLJS. At the end of talk they should have an understanding of the architecture and goals of re-frame, other alternatives to look into, and have a good line on where to go next to continue learning. - What is re-frame and how to use it from the perspective of a front end developer. Expects an audience who have built things in CLJS before, and could include deeper comparisons and analysis of other CLJS front end libraries. At the end of the talk they should almost be able to build a real app in re-frame (or as close as possible in 40 mins) and have a solid handle of where to go next. - An analysis of the architecture and design decisions in re-frame, including how the library has developed through its history. There would be a substantial amount of discussion about other alternatives in both CLJS and other languages (eg. Om.Next, Rum, DataScript, Elm, Redux, Hoplon) and how they have changed throughout their history. Would hopefully go a bit deeper into the principles of FRP, benefits and drawbacks of different approaches, and other concerns that are less relevant to actually building an application. Should be accessible by an audience with no significant background in any of these technologies. I’m pretty sure I could pull off any of these 3 talks and I’m committed to preparing something for the Conj regardless of talk acceptance (unsession or online) - any thoughts for discussion or preference on direction?
@shaun-mahood: I remember looking for a talk like 1 or 2 when I started using re-frame, but couldn't find any. I think my vote would be for 2!
@shaun-mahood Sorry for not making it easier 🙂 I'd be very interested in topic 3 because I settled on re-frame pretty quickly when I started with cljs. So to get a broader perspective on the other options in the CLJS field would be very insightful.
Heh, I just got done with abstractions, so I’m used to picking between 3-5 really good talks. 🙂 I’d go for topic 3, I think.
@shaun-mahood I’d prefer to watch 3, but that is as someone that is shipping production re-frame apps.
@shaun-mahood another vote for 3. The excellent re-frame docs are good for starters. Would be interesting to understand re-frame in the broader cljs landscape.
@shaun-mahood: I think the Conj is a good place for the deeper dive of 3, but you'll likely want/need some examples, so you would have a bit of 2 in there as well.
swirling around in my head right now is the fact that I want one “root container” that will be almost a top-level div in the app, and I want to put content into it— this will guarantee z-ordering issues don’t crop up, allow me to do background transitions, escape to close, etc.
but consumers of a modal need to be able to “do anything they want” as if it were a normal component view — hook up on-click dispatches, respond to ratom derefs, subscribe, etc.
on the surface these seem like conflicting agendas .. how can one render a top level modal container, but then later-down the component chain shove stuff into that container via the standard hiccup?
@lwhorton: Have you looked at how re-com handles modal panels? http://re-demo.s3-website-ap-southeast-2.amazonaws.com/#/modal-panel - I've used it a bit and it worked pretty well.
i did poke at that, but the problem is it requires a special api to be pre-determined that the model offers up
it offers things like
opacity, etc., but I”m curious if there’s a clever way to render any-old reagent component inside a totally unrelated modal container
@lwhorton: I also don't think that there should be any issues dealing with modals that are any different than anything else - if you've run into a specific problem I would be happy to look at it in depth with you to see if we can figure it out.
@lwhorton: Pretty sure those are totally separate concerns - you put all the
modal concerns into your modal div, and everything within that div is just a normal reagent / html / whatever component as if it weren't on the modal.
I've always treated modals the same as any other div and never run into problems, but that doesn't mean they don't exist.
i dont think i’m clearly stating the issue.. how about this for example:
(defn app-root [:div [content] [modal-container]]) (defn- content  [:div [foo] [bar] [baz]]) (defn baz  [:div [modal [:form [:input ...] [:button ...]]]]) (defn modal-container  [:div … ? ]) (defn modal [& children] [:div children])
conceptually this is how I would think of it — a container at the top level, the normal app content/components, then somewhere down the chain a particular component wants to “become a modal”.
and a nice api for that would be something simple like
[modal [ .. all the modal content ]]
except you can’t just pop up a modal right where the content is placed in the hierarchy, it needs to go to the top to avoid a whole bunch of issues - zindex, animation, click-capture, etc
@lwhorton: Right, so you have your modal container that has everything set up in that (zindex etc.). Then you dispatch an event
:display-modal that passes the content of your modal and go from there.
From your example, I think all you need to do is pass some arguments to your modal-container to let it know what you want contained in the div.
If that's not clear (which is very possible), I should be able to build an example that we can take a look at.
i actually have something like that working at the moment, at least if I understand you correctly.
the idea is the modal container subscribes to db/active-modal-content, and any consumer that needs a modal dispatches
display-modal args which sets db/active-modal-content.
but the annoyance is
:display-modal args where args might need a callback function, or many, or some other invocation of dispatch. if you try to follow “only dispatch data”, it’s incorrect and awkward to send functions across the re-frame dispatcher.
@lwhorton: No problem, wish I could be of more help. I might work on an example for how to do that anyway since it is relevant to some future work I need to do.
@shyambalu yes, pass a component as an arg- but also have the root of that component be elsewhere
i’ll probably end up doing some hackery with document.querySelector and
:component-did-mount to get what I need
@lwhorton: Could you treat the modal as a panel similar to https://github.com/Day8/re-frame/blob/master/docs/Navigation.md and deal with it that way? That's essentially how I did it in the past and is a more clear example of what I was trying to communicate earlier.
@shaun-mahood I could do that, but then I have a central switchboard component that has to know how many modals there are in the app, versus there being possibly dozens of “unregistered” components needing a modal that can get a modal without ceremony by simply declaring
(if some-state [modal args])
i don’t see why you can’t just stick an actual component into :active-panel and let it render
@lwhorton: Ok, that makes sense to me now. I've never worked on an app with requirements that made that into an issue, thanks for helping me understand the context.