Fork me on GitHub

 :width "200px"
 :style {:background-color "yellow"}
 :children [[rc/h-box
             :style    {:-webkit-flex-flow "row wrap" :flex-flow "row wrap"}
             :children [[rc/box :width "50px" :height "30" :margin "4px" :style {:background-color "red"} :child ""]
                        [rc/box :width "50px" :height "30" :margin "4px" :style {:background-color "red"} :child ""]
                        [rc/box :width "50px" :height "30" :margin "4px" :style {:background-color "red"} :child ""]
                        [rc/box :width "50px" :height "30" :margin "4px" :style {:background-color "red"} :child ""]
                        [rc/box :width "50px" :height "30" :margin "4px" :style {:background-color "red"} :child ""]]]]]


@gregg for reference the children of the h-box are hyperlinks. I've tried box'ing them before making them children,


i didn't think it was necessary but, JIC


otherwise my example looks pretty similar


except i am not specifying any :width's


okay so with :width on the v-box turns out to be relevant


if i change my code to put :width 200 on my v-box then the elements wrap


without it, they don't


of course i don't want to specify a fixed width


Should I have to specify a fixed width to get the row-wrap functionality? That seems odd.


There has to be a width somewhere so that the h-box knows where to start wrapping


this probably displays my ignorance of flexbox generally, i just assumed it would work out its own width


how very annoying


still many thanks for your example. at least now i understand why it doesn't work


so you can only have wrapping with fixed width layouts...


i guess i will never understand how these layout things get designed


Re fixed-width layouts, I would say no. The fact that you don't need to specify the width of the h-box itself demonstrates this. There just needs to be a component up the parent chain than bounds the h-box. It could even end up being the body component itself. You may have seen my favourite Flexbox guide ( It has an example in there that shows what I am trying to describe. The one with the orange boxes number 1 to 6


@gregg you're probably discussing with an idiot here... i have had a look at that guide (in fact i was referring to it when trying to figure out how to get wrapping to work in the first place). I guess I assumed that, based on the size of the window, the body at least knows what its size is. This kind of stuff is not my milieu (as I probably didn't need to tell you). I suppose I can set a specific width on the body but that seems inflexible.


Yeah, I wouldn't set a width on body, but I suspect you now have the key info to get a result which is hopefully acceptable


actually can you tell me what "bounds" means in your statement above? "There just needs to be a component up the parent chain than bounds the h-box."


do you mean by that "a component with a specified, fixed, width" ?


since any parent container is a boundary i assume you have a specific meaning for 'bounds' in this context


I guess bounds is a loose term and I probably can't give a complete and concise explanation, because there are a myriad of CSS styles that can affect the ultimate width of an element. It sometimes does my head in as well. Some elements can end up spilling past their parents width (because of the content they contain), and then you have the overflow style that introduces scroll bars (or prevents them) and margins and so on. But ultimately there is some parent that is going to affect the width of that h-box. It could be the immediate parent as in my example where we have specified one, or if it doesn't have a width, it could be another parent which either has a specific width or has an implicit width because of its parents and where it falls in the DOM hierarchy. Fun stuff indeed.


I'm having some real trouble maintaining my re-frame-tests because of the has anyone got any good ideas for solving this? My clear-timer hack didn't work too well. I imagine that 'pure re-frame' would fix it but I'm guessing that's probably not on the cards


@gregg where possible i want my app to use the full-width of the screen but, of course, all screens are different


at the top-level i have a v-box with width: 100% and it sounds like what i have to do is choose a fixed-width here


perhaps this is my naivety but i had assumed that if i specify width: 100% the box will fill the width but will know what width it is i.e. it will know how wide a boundary it throws around it's contained items. It sounds like what you're saying is that this assumption is wrong. That there must be some fixed-width component in the layout somewhere to provide a definite bounds otherwise things like wrapping will not function within the layout.


This sounds totally crazy to me but, then, so does most of CSS.


But see my latest


Github issue probably the best place for it, so others with similar queries will stumble upon it. Slack answers get lost forever in the mists of time.


@mikethompson thanks for the quick response! Really appreciate it:)


will try the purge-event-queue thing now


Is there an annotated example like ToDo MVC that deals with talking to a server? HTTP requests or even better some websocket integration?


@mikethompson thanks! seems to have both websockets and http/AJAX calls but as a newcomer to the entire ecosystem it would be nice to get a “sanctioned” example. I’ll keep exploring 🙂


@mikethompson re: the test stuff earlier, I was just having a look at run-test-async, and saw it relies on make-restore-fn under the hood- I was wondering if perhaps make-restore-fn should snapshot the queue, and replace it? Calling purge-queue inside make-restore-fn seems like it might not be exactly right. Or is it? I don't know 🙃


@sandbags I believe it should work exactly as you describe (width 100%) so are you able to provide a minimal version of your html that demonstrates this problem?