Fork me on GitHub
#fulcro
<
2018-03-06
>
tony.kay01:03:05

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.kay19:03:22

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

wilkerlucio21:03:29

@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?

tony.kay21:03:27

thinking…

tony.kay21:03:42

at the moment it sounds a bit too much like a personal habit than something that is a generally good idea

wilkerlucio21:03:45

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)

tony.kay21:03:03

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.

wilkerlucio21:03:12

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?

tony.kay21:03:42

I don’t but it adds yet another variant to an already complex macro.

wilkerlucio21:03:37

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

tony.kay21:03:51

I don’t disagree…I’m just trying to keep things tractable in terms of comprehension. Hard to know where to draw the line.

tony.kay21:03:33

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

tony.kay21:03:47

so, my preferred notation would be to name the table

tony.kay21:03:56

which is opposite of your preference

tony.kay21:03:37

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

wilkerlucio21:03:12

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)

tony.kay21:03:42

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

tony.kay21:03:27

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

tony.kay21:03:07

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.

wilkerlucio21:03:46

@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

souenzzo13:03:36

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

wilkerlucio17:03:02

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?

tony.kay21:03:57

and I addressed that

wilkerlucio21:03:49

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

tony.kay21:03:47

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

wilkerlucio21:03:52

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

tony.kay21:03:36

Give me a concrete example

tony.kay21:03:06

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 😜

wilkerlucio21:03:37

I like the discussion anyway 🙂

wilkerlucio21:03:06

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?

tony.kay21:03:50

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

tony.kay21:03:23

the original Om Next even had you declare what your ID field was called (for tempid remapping)…which I found too restrictive

wilkerlucio21:03:20

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

tony.kay21:03:51

OK, I can agree that your preference for declaring the ID column instead of the table is probably “better” in an objective sense.

tony.kay21:03:29

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

tony.kay21:03:51

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

tony.kay21:03:08

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

tony.kay21:03:32

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

wilkerlucio21:03:46

that's a good point

wilkerlucio21:03:02

the way I would handle this would be by pre-filtering the db before running specs on it

wilkerlucio21:03:20

like pulling the entities out of the tables before validating

tony.kay21:03:31

sure, and we’re back to your specific preferred use. If the vector bothers you, make a wrapper 🙂

tony.kay21:03:43

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

wilkerlucio21:03:30

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 🙂

tony.kay21:03:28

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?

tony.kay21:03:21

Being critical of my own code: I think the template form of :initial-state fails. I’ve considered deprecating it several times.

tony.kay21:03:43

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

tony.kay21:03:44

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)

wilkerlucio21:03:35

yeah, in reality my live template fills it for me, it's more a visual annoyance than anything else

tony.kay21:03:38

Initial state templates mostly are ok on 2, but the failure on 3 is significant I think…it is confusing.

tony.kay22:03:12

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.

tony.kay22:03:19

if I succeed 😉

wilkerlucio22:03:37

I'm pretty sure you can do it

tony.kay22:03:44

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

wilkerlucio22:03:10

ok, gotta leave the computer now, thanks for the chat on that

wilkerlucio23:03:08

@tony.kay what makes this timing special?

tony.kay23:03:48

That I was working on initial state in the defsc macro because I wasn’t happy with syntax deficiencies

wilkerlucio23:03:56

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