Fork me on GitHub

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.


Lein template updated to latest versions, and i18n ported to new alpha version


@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 don’t but it adds yet another variant to an already complex macro.


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


so, my preferred notation would be to name the table


which is opposite of your preference


and then (if I’m using Datomic) I’m constantly renaming :db/id


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)


why would they not expose :db/id???


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


In these case, we can use :app/squuid or something like.


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?


and I addressed that


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


why doesn’t a custom table name fill that need?


you mean just having everything wiht :db/id on the entity, but use different ident calls for each (just changing the table)?


Give me a concrete example


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?


I’m not suggesting either…but yes, I’m suggesting that that could be just as valid


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.


but let’s say you want to write a spec for your Fulcro app database


you can’t have a spec that says :account/id is both an pos-int? and a map?


I guess you could declare it to be an or, but then that seems really not so good


an :account/id is either an ID, or a table containing accounts?


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 🙂


you could have probably done that in the time it took to have this discussion 😉


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.


it meets 1, not always 2, and it fails at 3


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.


if I succeed 😉


I'm pretty sure you can do it


so, you hit me up on this at an interesting moment in time 😜


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