Fork me on GitHub
#re-frame
<
2019-01-02
>
WhoNeedszZz05:01:06

What's the typical method of checking if the client is mobile or desktop for providing different hiccup based on that response?

WhoNeedszZz05:01:33

I'd like to create a slightly different Material-UI Grid if it's a mobile client

WhoNeedszZz05:01:03

Is it as trivial as throwing an if at that point of the hiccup?

caleb.macdonaldblack06:01:09

And just hide the elements with css.

WhoNeedszZz06:01:18

There was a much simpler method within Material-UI in the old version. I don't know what happened to it

WhoNeedszZz06:01:07

So now I'm having an issue where I'm pulling up my site on my phone and it's being displayed as a desktop site out of the blue. Why is this happening?

caleb.macdonaldblack06:01:23

I've never used material UI so I'm not sure

WhoNeedszZz06:01:34

<meta name="viewport" content="width=device-width, initial-scale=1.0">

WhoNeedszZz06:01:44

Should be in the generated html, but it isn't

WhoNeedszZz06:01:32

Adding it solved it, but not sure why it wasn't there and clearly was at one point since it rendered correctly yesterday

WhoNeedszZz06:01:47

But I haven't touched the html

WhoNeedszZz06:01:09

Regarding the conditional rendering it was simply a property in the component

WhoNeedszZz06:01:42

{:desktop true}

WhoNeedszZz06:01:49

Something like that

WhoNeedszZz06:01:18

<Grid desktop container...>

WhoNeedszZz06:01:54

I'm trying to figure out this justification and alignment stuff. I want on the mobile site to show one card at a time so thus taking up the full 12 grids, but because there are two items in the container when wrap is enabled it will left justify. How do I get it to stay in the center?

WhoNeedszZz06:01:21

I want them to be on top of each other in the middle of the page

WhoNeedszZz06:01:29

But they are on top of each other and left justified

WhoNeedszZz06:01:03

But I have {:justify "center"} on the container

WhoNeedszZz06:01:00

On desktop it is centered

WhoNeedszZz06:01:07

Why does it left justify?!

WhoNeedszZz06:01:18

Oh hey. So to disable on a certain breakpoint you just set it to false

WhoNeedszZz06:01:40

{:xs false :xl 3}

WhoNeedszZz06:01:44

I think if I set on mobile to have separate containers for each single item then it will center on the page, but I feel like there is a way to do that without the repeated code

WhoNeedszZz07:01:29

Well then. Just had to set :xs to 8 instead of 12

WhoNeedszZz07:01:36

CSS is such a PITA...

valtteri12:01:11

@whoneedszzz this is a bit off-topic for this channel but anyways: MaterialUI has a few helpers to deal with different screen widths. hidden is a simple component to hide its children based on screen width. https://material-ui.com/layout/hidden/#hidden withWidth is a higher order component which injects property width with possible values (‘xs’ | ‘sm’ | ‘md’ | ‘lg’ | ‘xl’) to your component and then you can conditionally modify your hiccup based on those. It provides more flexibility than hidden, which actually uses withWidth under the hood. https://material-ui.com/layout/breakpoints/#withwidth-options-higher-order-component

mikethompson12:01:17

@lilactown I'm looking to experiment with Apollo Client. From your point of view, does this repo still represent good practice for using apollo from Reagent? Anything go wrong in your experiements? Or any gotchas? https://github.com/Lokeh/apollo-reagent

mikethompson12:01:24

BTW, I notice this is using shadow-cljs, so I assume that Apollo's npm modules were too much for lein?

WhoNeedszZz12:01:30

@valtteri Thanks for the info. Digging through that more it seems like the simplest would be to use: https://material-ui.com/layout/use-media-query/#using-material-ui-39-s-breakpoint-helpers

valtteri12:01:12

Yep, that’s the newcomer. I didn’t mention it because it’s still considered “unstable”. However, if you try it I’m interested to hear your experiences!

WhoNeedszZz12:01:22

Aye, I did note that it was new. After realizing my problem earlier was just me not quite understanding MUI Grids I don't currently need to do the conditional rendering. If it does pop up for something else I'll try that approach first and report back.

5
Whiskas13:01:42

someone knows what this :<- stands for?

(re-frame/reg-sub
:value
:<- [:doc]
(fn [doc [_ path]]
  (get-in doc path)))

madstap14:01:50

It's sugar for

(re-frame/reg-sub
  :value
  (fn [_ _]
    (re-frame/subscribe [:doc]))
  (fn [doc [_ path]]
    (get-in doc path)))

rutledgepaulv19:01:50

Hi all, I’m pretty new to reframe and trying to wrap my head around some approaches. If I have some small components like buttons and I want their effects to be driven by whatever containing components they’re in (several layers deep), should I: - pass data down from the parent component to the child to parameterize the effect - pass a function down from the parent component to the child for the child to invoke - find ways to bubble the event from the child to the parent which can then emit the desired effect - decrease the nesting and inline actionable components into the parent component instead where scope is shared - have the parent stage a “desired effect” in the db and have the child emit an effect whose job is to emit the desired effect? - something else?

isak20:01:05

@rutledgepaulv I'd go with > pass data down from the parent component to the child to parameterize the effect

rutledgepaulv20:01:14

should have made this a poll. thanks!

PB21:01:15

Maybe a newbie question. There is one page in particular which does a get on a resource and the data from that resource is stored in the app db. Here is an example: The response from the server is something similar to

[{:username ""
  :houses [{:location "Somehwere" :completed true}
           {:location "SomeWhereelse" :completed false}]}
 {:username "[email protected]"
  :houses [{:location "moon" :completed true}
           {:location "jupiter" :completed false}]}]
If I wanted to update house completion for any of these users, I would need to first find the index of the username I wanted to update, then find the index of the house I wanted to update, then do an update-in/replace in using those indexes. So it seems to make more sense to store these values as such
{"" {:username ""
             :houses {"Somewhere" {:location "Somewhere" :completed true}
                      "SomeWhereelse" {:location "SomeWhereelse" :completed false}}}
 "[email protected]" {:username "[email protected]"
                  :houses {"moon" {:location "moon" :completed true}
                           "jupiter" {:location "jupiter" :completed false}}}}
This would allow me to easily update those values. Is this unconventional? Another option would be to return the entire user entity from the database each time a change is made and have that method update the app-db? I'm unsure of what the correct way to handle this would be. Any thoughts?

madstap21:01:22

There's a nice article about this, scroll down to Indexed Entities https://purelyfunctional.tv/guide/database-structure-in-re-frame/

🙏 5
✔️ 5