This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-03-06
Channels
- # aleph (2)
- # arachne (4)
- # aws (3)
- # beginners (196)
- # cider (131)
- # cljs-dev (208)
- # clojure (193)
- # clojure-boston (1)
- # clojure-dev (26)
- # clojure-greece (4)
- # clojure-italy (26)
- # clojure-losangeles (1)
- # clojure-russia (11)
- # clojure-spec (40)
- # clojure-uk (78)
- # clojurescript (168)
- # cursive (25)
- # datascript (1)
- # datomic (31)
- # docker (8)
- # docs (1)
- # emacs (20)
- # fulcro (62)
- # hoplon (3)
- # jobs (1)
- # leiningen (3)
- # luminus (1)
- # nrepl (25)
- # off-topic (10)
- # other-languages (3)
- # parinfer (11)
- # planck (37)
- # portkey (54)
- # protorepl (11)
- # re-frame (2)
- # reagent (19)
- # remote-jobs (1)
- # ring (2)
- # rum (8)
- # shadow-cljs (23)
- # spacemacs (4)
- # uncomplicate (6)
- # unrepl (77)
- # vim (56)
- # yada (2)
Fulcro template (the sample project) updated to use the new alpha i18n for SSR and client-side. Demand loading directly from PO files is now a thing, and no more code generation.
@tony.kay hello, checking my code, pretty much all my :ident
definitions on defsc
look like: [:customer/id :customer/id]
, [:account/id :account/id]
, [:blabla/id :blabla/id]
, would be willing to take a version of :ident
that accepts a single keyword and expands to that?
at the moment it sounds a bit too much like a personal habit than something that is a generally good idea
my reasoning is this version takes less translation effort, you just say what it is, I never have to convert things like :customer/by-id
to :customer/id
on my backend (when querying for idents)
for the moment I’d suggest making your own wrapper. defsc
the macro is very very tiny. You could make a wrapper that converts the incoming ident from a kw to a vector, and then use defsc*
to do the rest of the work.
nah, I don't lke that, seems an unscessary macro to have, I rather just keep doing the vector than do that, but I don't see why fulcro can't support it, do you see any way this could affect people that don't want to use this format?
I honestly think we should encourage that, the by-id
convention seems to me a waste of extra name definition, we create a new name for the same semantic value, only to have the table name "look more descriptive", but I understand if you don't agree
I don’t disagree…I’m just trying to keep things tractable in terms of comprehension. Hard to know where to draw the line.
from my perspective, having a different kw for every ID (instead of :db/id) makes little sense, since then I have to have a spec for every ID type, which are likely to be all the same
I though for a time about having a single id (like :db/id
), but that's not practical, even for people using datomic, they usually don't expose the :db/id
, so having different tables is a good thing IMO, I just don't like creating extra names when they are not nescessary (`by-id` things)
you have to expose some kind of ID. If you’re using uuids then maybe it is :db/uuid
, but it’s likely you made the same decision everywhere
so again, I’d rather name the table…and that makes me not want to add an added convenience. You can make a good case for it meaning one thing, and I can easily argue it works better a different way. At the end of the day, naming both is very easy.
@tony.kay about the db/id: if you have a microservice architecture, you will have multiple datomic databases, and since :db/id is serial you could have collisions, that's why we don't do it here
but then you still have problems to find it, for example, if I get a :customer/id
and wanna get the information for it, I know I should call the customers
service, but if all I get is a :app/squuid
, how can I know in which service that data lives?
but having custom ids can narrow the search space, and for things like Pathom on microservices would be hard to live without then (in which service I would look for that ident?), it's a type of filter we can say
you mean just having everything wiht :db/id
on the entity, but use different ident calls for each (just changing the table)?
actually, you’re probably wasting your time…I am interested in your use-case, but it is doubtful you’ll convince me on this sugar 😜
I like the discussion anyway 🙂
like this: entity: {:db/id 123 :user/name "bla"}
, :ident :user/id
, so that would generate equivalent of todays [:user/id :db/id]
, is that what you are suggesting?
the original Om Next even had you declare what your ID field was called (for tempid remapping)…which I found too restrictive
I see a few problems with that:
1. making :db/id
especial in some sense
2. this doesn't help on the parsing process, if you agree that on the server having specific ids instead of a global helps to narrow the search, the same thing leaks for the client, not having the same (name -> name) association would require server translations, and would make the parsing things more difficult
OK, I can agree that your preference for declaring the ID column instead of the table is probably “better” in an objective sense.
that's a good point
the way I would handle this would be by pre-filtering the db before running specs on it
like pulling the entities out of the tables before validating
sure, and we’re back to your specific preferred use. If the vector bothers you, make a wrapper 🙂
it's not about that anymore, now I'm trying to understand your view and learn from it, the point on spec is something I didn't though before and it's good that now I'm aware of it 🙂
that one is just a “tie breaker” from my perspective. The real thing I’m ultimately worried about is adding tiny sugar. Here’s rough criteria I use for deciding when to add syntax: 1. Does the new syntax reduce boilerplate to a significant degree 2. Does it always help everyone. 3. Do the negative aspects of the syntax cause any harm?
Being critical of my own code: I think the template form of :initial-state
fails. I’ve considered deprecating it several times.
yours meets 2 (if “everyone” is defined as everyone that uses it). IMO it does not meet 1, and it is borderline on 3 (potential confusion)
yeah, in reality my live template fills it for me, it's more a visual annoyance than anything else
Initial state templates mostly are ok on 2, but the failure on 3 is significant I think…it is confusing.
I am actually coding a fix as we speak to make templates allow mix-and-match of get-initial-state
, which I think will help with confusion.
I'm pretty sure you can do it
ok, gotta leave the computer now, thanks for the chat on that
@tony.kay what makes this timing special?
That I was working on initial state in the defsc macro because I wasn’t happy with syntax deficiencies
ah, gotcha, yeah, mind sync 🙂, I'm revisiting some code from work with that, we might start to add a lot of more code sooner than later, so I want to polish it so we have a good reference for others doing implementations