When using compojure-api + swagger, like in this screenshot: http://i.imgur.com/S6eQNU3.png do you know where is Body46670 coming from? can I control it?

@pupeno: You can define your schema using schema.core/defschema

deraen: oh, is that because I’m passing the schema definition as a literal instead of calling defschema?

@pupeno: Yes

You can also set name metadata manually: (with-meta {schema} {:name "Body"}) though then you need to be careful to avoid name clashes

Thanks.

I seen schemas using camel case instead of kebab cases. Is that the convention?

Yes

I’m thinking of keeping my code grouped by object type and not function type, that is, the namespace foo.models.user contains the user schema, and validation and creation function and so on. Does this make sense or am I thinking in OO?

what do you mean by “function type”?

@pupeno: Yes, organizing code by "object type" makes sense. I would call if organizing by topic, like one namespace for user stuff and other for groups.

@pupeno: Also, if you are doing Clj+Cljs app, you should separate your Schemas to Cljc namespace so that you can use them from Cljs.

So, pprint has the same problem as println, where you can get lines out of order

I use (pprint/with-pprint-dispatch pp/code-dispatch (pp/pprint ...))

How would I fix this so I don't get interleaved output?

like:

(defn safe-println
  ""
  [& more]
  (.write *out* (str (str/join " " more) "\n")))

https://blogs.law.harvard.edu/philg/2015/10/12/clojure-if-lisp-is-so-great-why-do-we-keep-needing-new-variants/

That's Philip Greenspun of Greenspun's 10th law

@juhoteperi: yes, I’m starting to use cljc.

I’m finding myself moving whole namespaces from clj to cljc and putting almost everything inside a clj conditional so that some code can be shared between clj and cljs without having artificially named namespaces. Is this common?

@pupeno: I keep clj code to clj files and use conditionals pretty much only for require forms.

Really?

Well, for example, I have projectx.models.user, which RegistrationSchema and registration-validator. Most of the extra code to save users to the database and so on will be clj only.

Even code that could compile to both, if I’m not using it in js, I’d rather keep it out of js.

No sense to write database code to cljc files, it will never be common.

deraen: yeah, but then how should I name my namespaces? projectx.models.user and projectx.cljc.mdodels.user?

I use "domain" namespaces for Schema namespaces

Can you elaborate on that please?

Something like: common.domain.user, backend.user, frontend.user (or backend and frontend namespaces could be split even more: backend.user.routes, backend.user.db, backend.user.x)

I see.

and common namespace has also something like common.dates, commom.transit (for transit handlers)

Is it a bad idea to (catch Throwable …) inside of a (binding […] …) form?

chrisfarber: example?

This is roughly something I was doing: (binding [*bypass* (conj *bypass* id)] (try (stuff) (catch Throwable e e)))

the binding was never returning, even though (stuff) did. I refactored the try outside of the binding and it all seems to work

I suspect I’m doing terrible things

yes that’s a bad idea

pass an exception handler down the stack or catch exceptions at the boundaries of the app

otherwise you will swallow errors by mistake

pupeno, I find that if I have a .cljc file with almost entirely Clojure or ClojureScript-specific code (i.e. a ton of reader conditional annotations) it’s a bad sign and means I probably should have just moved the small bit of code that is really appropriate to be shared to a new namespace, and leave the rest as either a CLJS or Clojure-specific namespace

YMMV

@ddellacosta: I sort of feel the same way, but I also feel that way about arbitrary namespaces.

I don’t know what you mean by “arbitrary” namespaces

Well, let’s say I have a namespace called projectx.models.user with all the functions related to creating new users, activating users, validating fields, etc. Now, I want to re-use those validations in ClojureScript so I want to move part of it to a cljc file. What should the namespace be?

I don’t know, I’d have to understand more about what the functions are that you are moving to a cljc file

presumably they are related to each other…otherwise they shouldn’t be in the same namespace, right?

Well, for example, UserSchema, UserRegistrationSchema, user-registration-validation.

Yes, they are all related to users.

I’m still not getting your point—seems like there’s nothing arbitrary here

I mean, why would you need to move those in that case? if you are talking about schema validations, they can use the same code anyways

Yes, having a namespace be called something like projectx.cljc.models,user would be arbitray.

it’s hard to talk about hypotheticals here—I’d have to have a more concrete example

This is a concrete example.

right…but I’m not sure why you’d need to move a bunch of schema validations to a separate namespace in the first place

assuming that’s what you’re talking about re: validations

I need to move them to a different file, to a cljc file, so they can be used from clojurescript too.

okay, I think we are talking in circles

I was simply suggesting that if you have a cljc file that has a ton of reader conditional annotations

that’s probably a smell

i.e., in the ideal usage of cljc you’d have a bunch of code that you don’t necessarily need to customize for CLJS or Clojure

just a few platform-specific exceptions

(that’s what I’ve found at least)

Ok, let me try again. projectx/models/users.clj contains all the functions related to users. Some of the functions need to be accessed by clojurescript, so I need to move them to a cljc. What should I call thes cljc file?

I don’t know…what are those specific functions? Haha

what is the unifying concept around those functions such that they are distinct from the others and can/need to be used in CLJS?

For now, schema definitions and user validation.

again, why do those need to be separated? Schemas can be written cross-platform

...and we get back to where we were before.

I want to have them crossplatform, that’s why I want to put them on a cljc file.

okay, so that’s fine then, right?

I mean, I think there is something I’m missing, I’m sorry

No, it’s not fine because I don’t have a name for the cljc file.

seems like a totally reasonable use-case

how about: user validations

I dunno, it’s not arbitrary as far as I can tell—you explained it pretty clearly

the schemas are not validations, they are schemas, and vice versa.

For example, the helper function that builds the display name out of a user record (first name + last name) would be shared, and that’s not validation either.

They are all functions related to users, but I can’t call it projectx.models.users, that’s taken.

Or rather, since one file would have to use functions from the other file, and they can’t include it, I would have to use declarations.

Does it make sense now?

sorry I think I’m a bit out of it today.

No problem.

but yeah, back to the point at hand, I think that it can show a potential problem in organization if you have a ton of annotations, but sometimes it makes sense—I suppose in your specific case this could be true. Or maybe it makes sense to put all the DB-specific code for a model in one place and leave the other stuff in your “…models.cljc” namespace, etc. Definitely didn’t mean to suggest it’s always going to be cut-and-dried.

sorry if I came off as argumentative, definitely didn’t intend to (seriously, think I’m out of it today…need more sleep! sigh)

@ddellacosta: I’ve seen impl namespaces used for this pattern

(ns projectx.models.user
  (:require [projectx.models.impl.user :refer [fn-1 fn-2 fn-3]]))

; Platform independent code/fns go here

where there are two files src/projectx/models/impl/user.clj and src/projectx/models/impl/user.cljs

@jr are you saying, and then the main ns is cljc?

(and src/projectx/models/user.cljc)

ah, gotcha, right

yeah, seen that pattern here and there

seems reasonable

I like it because it minimizes code reloading

dunno, I guess I also find that stuff tends to group itself together naturally too based on function—stuff that is surrounding DB insertion/extraction can be isolated, for example

but again, really probably is case-by-case, and the impl thing is a common enough idiom

Seems like excessive consideration just over a namespace naming issue

pupeno: on my current project i ended up with projectx.users.schema.cljc and projectx.users.model.clj with the schema.cljc containing schema, validation and coercion stuff and the model.clj persistence related stuff