Fork me on GitHub
#om
<
2016-03-13
>
seanirby00:03:30

having trouble triggering a rerendering a sibling component after a mutation. See the comment below

(om/transact! this `[(face/update {:face ~id :background ~(rc)})
                                          [:faces/by-id ~id]]) ;; I want to update the component that has this ident but its in a different path in the UI tree

krchia09:03:25

is it possible for an user to check app-state through the client console?

krchia09:03:07

what kind of things are not safe to store in the application state?

cjmurphy10:03:02

@krchia: I've stored core.async channels and two types of dates (google and Javascript) as data in app-state. I'm not really sure what kind of data couldn't be stored in application state. Did you have some kind of complex data type in mind?

krchia10:03:12

@cjmurphy this is going to make me sound dumb, but i was thinking of things you’ll normally store in a ring session key

cjmurphy10:03:47

As far as checking app state through the client console you can just @reconciler. But I prefer to have state be checked for me using https://github.com/chrismurrph/default-db-format.

krchia10:03:32

i guess what i’m really asking is about the difference between storing stuff in ring sessionstore and om app-state

cjmurphy10:03:18

I can't see why there would be a problem.

cjmurphy10:03:37

(cljs.pprint/pprint @reconciler) in the render of your root component (or from a button or something) good for debugging.

krchia10:03:44

the way this project does is, he just stores a keyword :auth/success in om app-state

cjmurphy10:03:23

You can store keywords in your app state for sure!

krchia10:03:39

would sensitive data be safe in there?

krchia10:03:08

sorry, i’m learning both web security and om at the same time, so my questions might not make sense

cjmurphy10:03:42

I'm a bit the same so hesitant to answer security questions.

krchia10:03:59

i mean the om app-state lives on the client right? is it possible for a malicious party to manipulate it?

krchia10:03:40

maybe i haven’t done enough homework to properly formulate questions yet

cjmurphy10:03:08

No I think its a good question, but not a show stopper. Of course can be encrypted. I've started to use sente as well.

cjmurphy10:03:30

The answer will be the same for Reagent. https probably the best thing if you really need security. I read it is very easy with sente - just turn it on and it works.

krchia10:03:56

say if you authenticated through websockets and you store the session information on the app-state

krchia10:03:41

would everything be reloaded if you went to another url?

cjmurphy10:03:32

My experience (which is limited) is that session does not need to be stored anywhere. It just kind of flows back and forth from client to server.

cjmurphy10:03:00

I'm relatively new to web programming - that was my recent discovery.

cjmurphy10:03:13

Good questions - maybe ask again on Monday. 😜

krchia10:03:50

and in between, a lot of reading simple_smile

krchia10:03:55

thanks for entertaining my questions

rauh11:03:24

@krchia: Anything you send to the client can be seen by the (potentially bad) client. Even if you don't display it and it only lives in some JS variable. Anything you receive from the client you should NOT trust. It could be changed. Generally speaking: If you want to rely on state not being readable you need to encrypt it. If you want state not to be writable then you need to chryptographically sign it. An example: You receive the user-id from the client and display sensitive data associated with it. You cannot trust that the user didn't change the user-id so you need to sign it. Alternatively you can use a random session ID that is secret and looks up all the information instead of signing your state.

krchia18:03:45

@rauh: thanks for explaining it to me in the simplest way

krchia18:03:02

i don’t completely understand but i think i have a better mental model of how to go on now

bpicolo19:03:11

Hi friends. I'm just getting started with om. I see it's built around global state, but how should I deal with state that I expect to appear on a single page?

bpicolo19:03:27

I haven't found a good pattern looking through examples

bpicolo19:03:29

Should that just be state on a component? How do I pass it down? Do I not pass it and use channels instead?

bpicolo19:03:21

Granted this might be easier if I knew exactly what owner was in the context of a component. I can't find a direct definition for that in docs either : (

bpicolo19:03:31

aha, there it is

hlolli21:03:36

Is it possible to throttle in om.next. I just switched from using js/setInterval for updating my app-state into using transactors on window/RESIZE events. And I notice my computer goes spinning wild when Im resizing a window and I see uuid generated every 0.002 second. How could I slow this down?

hlolli21:03:30

wow I think I just answered my own question writing the question. I just use js/setInterval in the function call of goog.events, because it sure wont be doing anything if Im not resizing the window. pff, one of those times just writing the question the answer is right in front of you.

hlolli22:03:41

Well my cpu still goes from 12% to 50% when resizing a window, I just post my code here for this experiment of mine, code speak louder than words. https://www.refheap.com/115923

bpicolo22:03:32

Are channels the sanest way to talk to parent/child components

hlolli22:03:30

you mean go channels?

bpicolo22:03:01

hlolli: core/async

hlolli22:03:31

with the warning that Im a beginner in om, then in all the tutorials I've done and articles I read, it seems to be the strive to get away from core.async, because the async is handled in react/om (Im probably inaccurate), but you should rather try to pass in your state into the components via the factory, or if you need mutation, via a reconciler. Are you learning om.now or om.next?

bpicolo22:03:30

Haven't seen those terms : (

bpicolo22:03:14

So say I have these elements: page - box - things in box -thing in box

bpicolo22:03:19

box keeps track of a list of things

bpicolo22:03:28

and -thing in box wants to be able to delete itself

bpicolo22:03:19

currently om docs seem to suggest a channel approach

bpicolo22:03:24

e.g. their todomvc example

bpicolo22:03:48

this is local state rather than backend-related state

hlolli22:03:49

that's bit outdated tutorial, read rather om.next quickstart and read it many times, word by word, took me 4 weeks actively every day to understand the basics of om. (at least thats what I recommend)

bpicolo22:03:08

om.next isn't even mentioned on their readme

hlolli22:03:28

Also I recommed watching the two lectures of david nolen on om-next, gives you the motivation to go trough the "pain" of understanding om.

bpicolo22:03:48

I will probably stick to rest for now