Fork me on GitHub

well, for a starter, look at and why not write all-complete? @(subscribe [:all-complete?]) instead of @all-complete? further down?


There’s some really important concepts in there for using reagent/re-frame


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


Create the sub in the outer function, deref it in the inner one


@danielcompton thanks - yes familiar with that


but what if there is no inner render function, i.E. form 1?


you shouldn’t use a form-1 if you need a data subscription


@michael.heuberger In that case, I think you might need to go over the re-frame docs again, perhaps from this point on:


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


With Form-1 you recreate the subscription each you rerender.


It isn't one susbcription delivering a stream of updates.


It is a new subscription each time you rerender


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.


So, if it is to come about then it will be in a future release


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”?


if so, why? … would be good to know


right, but: "may actually work (theory untested)”


good, thanks for the confirmation - all clear now


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


many thanks - is there a github ticket re: #2 i can follow?


I'll create one 🙂


thank you - that’s a good, probably important, ticket @mikethompson


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.


(and then I’d hope someone recorded the other 2 so I could watch later)


another vote for topic 3


@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.


yeah, I'd vote for 3! :)


@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.


@shaun-mahood .. My vote for #3 as well...


has anyone come up with a “clean” way to do modals/dialogs?


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? - 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 backdrop-on-click, 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 

(defn- content []

(defn baz []
     [:input ...]
     [:button ...]]]])

(defn modal-container []
   … ?

(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.


either way, thanks for your thoughts, i’m going to sit and think on this for a bit


@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.


@lwhorton essentially you want to pass a “component” as an arg right


i was thinking about something like this for routing


i was thinking about how to do react-router functionality in re-frame


where the route defines the component hierarchy and components get hot loaded in


@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


why would the root of the component need to be somewhere else


aren’t essentially hot loading a component into the model


of which was defined by the calling component


@lwhorton: Could you treat the modal as a panel similar to 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])


yep that’s the problem i got stuck at


i don’t see why you can’t just stick an actual component into :active-panel and let it render


not actually tried it


essentially components become part of the app state


@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.


btw this might be a dumb question


but who or what is Day8


@shyambalu: For re-frame purposes I believe it's primarily @mikethompson, you'd have to ask him for any specifics.