This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (18)
- # announcements (1)
- # asami (99)
- # babashka (4)
- # beginners (45)
- # calva (20)
- # cider (44)
- # cljdoc (5)
- # clojure (66)
- # clojure-australia (2)
- # clojure-europe (36)
- # clojure-nl (11)
- # clojure-norway (4)
- # clojure-seattle (1)
- # clojure-uk (88)
- # clojurescript (37)
- # community-development (8)
- # conjure (8)
- # datascript (4)
- # datomic (29)
- # depstar (12)
- # emacs (7)
- # events (1)
- # fulcro (29)
- # graalvm (4)
- # graphql (2)
- # helix (2)
- # integrant (4)
- # jobs (7)
- # jobs-discuss (1)
- # lsp (3)
- # malli (6)
- # off-topic (61)
- # pathom (67)
- # pedestal (3)
- # re-frame (9)
- # reitit (4)
- # remote-jobs (13)
- # reveal (18)
- # shadow-cljs (59)
- # spacemacs (1)
- # sql (7)
- # startup-in-a-month (1)
- # tools-deps (29)
- # vim (12)
Is this example of how to use local-storage as a remote still functional with Fulcro 3.0+? (I’m getting build errors with missing namespaces for fulcro.client.primitives and fulcro.client.util. I’m guessing it has changed https://fulcro.fulcrologic.com/networking/2017/12/26/remotes-as-an-abstraction.html
@aleksander990 I don’t see any of those namespaces in fulcro 3. There is a mock_server_remote.cljs that I’m sure you could repurpose easily enough to have as a local storage remote.
I made a little helper to make this nicer to use (just takes a pathom parser) https://github.com/dvingo/my-clj-utils/blob/master/src/main/dv/fulcro_util.cljs#L553
F3 dropped the use of protocols for most things (they don’t DCE in Closure, and are a bit of a pain when you need to flex them). So, yeah, the idea is still solid, but the implementation has different namings. The suggestion of the mock remote is spot on.
fwiw @stuartrexking I'm also doing auth now, but using firebase, which I much prefer so far over my previous experience with cognito. It has its own state-machine I gather, but I'm still wrapping it with my own uism. I'm not doing much with routes yet. Whenever someone interacts with a db part I log them in anonymously and ask them to "sign in to save progress" by linking that account with their oauth or so. I think that works quite nicely so far!
@bbss Firebase is great, but I’m all in on AWS with Datomic Ions and the other niceties it has out the box. I’ve implemented a simple solution for authentication and authorization, mostly based on the RAD attempt. At the top end I load either one of two different routers, one for authenticated state or one for unauthenticated. For authorization I use a set of permissions from the session state in the component themselves, and have a component option ::auth/permissions that is used by an authorizer. If the one of the permissions in the session state match the permission in the component the the body is rendered. It’s simple and covers my needs at the moment. On the server side I’ll do something similar in the pathom environment for the authenticated user.
Because I’m only using AWS, Cognito makes more sense than any other auth service, even if the docs and examples are still lacking.
Although they are not too bad to be honest.
Ah yeah in datomic ions case I understand going with cognito. It’s actually where my experience with cognito came from. Took a while before I figured out how to set up all the api gateway and hosted zones stuff. I thought the docs weren’t great.. Especially after seeing firebase docs.
It takes a little fiddling but I feel the learning curve is worth the leverage you get. It’s the same with Fulcro IMO, steep learning curve but great leverage.
Hey folks! I want to start a little hobby project to learn and play with the Fulcro + EQL/Pathom stack. For persistence on the backend, I'm torn between sticking with what I know (raw jdbc/postgres or a graphql postgres wrapper like hasura/postgraphile) versus something datalog (datahike, or datomic dev-local). Since my focus is on Fulcro+EQL, do I hurt that or enhance it by using datalog to write pathom resolvers?
I think it does not matter that much. Perhaps stick with what you already know since you have a lot to learn already? You could argue that datalog would be an easier backend for a graph api but it depends on your actual domain and data model, IMHO.
@tony.kay hey there 👋 , I've a question for you about guardrails. Is it possible to disable it for only some namespaces? Here's the two use cases I have:
• I have a ns that that makes heavy use of guardrails, and an app that makes light use of guardrails. That ns is a rather important part of the application but makes it very slow due to guardrails. Right now if I want to have performant app development, I have to wholly disable guardrails for both.
• I have a library that makes heavy use of guardrails and a consumer that also wants to use guardrails. This is essentially the same as the above except the consumer doesn't have any agency over the library.
If you're interested in this functionality and it doesn't exist, I'd implement it. I'm thinking
allow/`deny` lists in the build config (kinda like timbre) but don't really have a strong opinion about it.
Are you implying that you use GR in production?? Have you tried async mode in CLJ? Disabling it for some namespaces seems like an antipattern to me, since the whole point is to catch data flow errors during development. That said, I can see your point of not having control of a possibly inefficiently spec’d library that is causing dev time slowness that you don’t want. There is no current feature, but should be trivial to implement at the macro level I would think.
no, no, I don't using it production
I use it on a cljs project
on dev mode
the particular ns that makes heavy use of guardrails is a datascript sync engine that I mostly maintain
other devs maintain other parts of this web app
but because I've used guardrails so much, the whole app gets very slow during development
there's probably some low hanging fruit that I could just spec to
any? that would massively increase perf while developing, but that itself feels like an anti-pattern
my thinking is that I'd turn it on while actively developing that ns, and that other devs that aren't interacting with it would leave it off
meanwhile unit tests and generative tests would always leave guardrails on too
I also think at a macro level it would be very straightforward, but didn't want to put up a PR if this wasn't something you were interested in having in guardrails to begin with
to be honest I was just going to work around this with some goog.define conditionals, but @U066U8JQJ convinced me that the principled approach would be to propose the filtering