Fork me on GitHub
#admin-announcements
<
2015-12-22
>
sveri09:12:58

Hi, how can I tell prismatic schema a value in a map could be nil or string?

robert-stuttaford09:12:15

there’s always s/pred

mccraigmccraig09:12:02

@sveri: or (s/maybe s/Str)

sveri09:12:18

ah, so I can just leave out nil

sveri09:12:25

that makes sense, thank you both

andrut11:12:01

regarding schema - how do you guys organize your schema code? do you put your schemas next to the place you create data or you have a separate namespaces for schemas?

mccraigmccraig11:12:55

@andrut: both, depending on usage. i've got some schemas which are shared between cljs ui and clj backend which are in their own namespaces, and others which live near the code which uses them

andrut11:12:37

I’ve got quite a lot of same data structures that are being passed around the whole application; maybe I should put it into records and use this as schemas or should I leave it as plain maps and define schemas somewhere… simple_smile but thanks for your answer, @mccraigmccraig

sveri14:12:04

@andrut: I also have on file containing my schemas which are shared

sveri14:12:31

Hi, I lately switched from component to mount. Now I see a behavior I find strange, but I am not sure if that did happen before with component too. So, I have several things defined with defstate. I use Cursive and whenever I adapt a function in a namespace and reload that changed function into the REPL the component, that that code belongs to, is stopped and I have to start it manually again. This is somewhat unexpected as most of my components stop after changing some code.

eggsyntax14:12:04

@jonpither: post in #C0F0V8DT5 & you’re likely to find some help.

sveri18:12:53

I just put it all back to components and at the first glance the problem has gone now

roberto18:12:41

that sucks. I just started using mount on a new project. Would suck if I don’t get code reload.

roberto18:12:51

Did you use the dev.clj file in the example?

sveri19:12:45

@roberto Don't get me wrong, it does reload the code. But, what it does, is, to stop some components

sveri19:12:50

And I have to start them manually

sveri19:12:54

It works afterwards again

sveri19:12:00

but, that extra step bugs me

sveri19:12:19

OTOH I have several complex with a lot of dependencies thrown together, the cause might also be a different library

sveri19:12:41

So, not sure if it is really mounts fault or someone elses, I just think the tendency is there

sveri19:12:21

I also searched github for how others used it and did not really find any repos doing so. That means it is in kind of early adopters state and I think there are more bugs around that are not found yet.

settinghead20:12:19

FYI i created a channel #C0GQAAKA9 for discussions related to component-based workflow

sveri21:12:15

@settinghead: thanks, didn't know that

tolitius22:12:37

@sveri: when you reload code which does not have any states defined, it reloads as you would expect. when you reload with states defined and started, new states are created with, potentially, new changes introduced before recompilation. hence before creating these new states, mount cleans up any resources old states might be still using by calling their :stop functions. currently (starting from 0.1.7) mount will tell you when it happens: https://github.com/tolitius/mount/issues/22#issuecomment-164834038 if you are using the reloaded workflow, you can simply (reset) if this happens, and/or you can do (mount/start #'this.state). I understand that it is an extra step, you can open an issue on the github and we can definitely discuss whether mount should just start these new states after a namespace was recompiled, or ignore certain states on recompile if they are not occupying any resources, etc.. so things are more transparent

tolitius23:12:04

@sveri: another thing to consider is how to organize the code with "states". I tend to agree with @yogthos that it is best to > "keep the code that interacts with external resources at the edges of the application. The core business logic should be pure and testable, while anything that deals with side effects and external resources should be pushed to a thin layer around it" source: http://yogthos.net/posts/2015-12-05-LuminusComponents.html in which case reloading the code with states would not be often at all. I would still like to discuss it though, since I am interested in the useful behavior, so feel free to open a github issue