This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-09-20
Channels
- # aleph (1)
- # announcements (1)
- # aws (11)
- # babashka (117)
- # beginners (34)
- # calva (13)
- # cider (3)
- # clj-commons (8)
- # clj-kondo (24)
- # clj-yaml (36)
- # cljsrn (46)
- # clojure (50)
- # clojure-australia (5)
- # clojure-europe (239)
- # clojure-nl (3)
- # clojure-norway (3)
- # clojure-spec (16)
- # clojurescript (25)
- # core-typed (20)
- # cursive (41)
- # datahike (1)
- # datalevin (1)
- # datomic (17)
- # fulcro (27)
- # hyperfiddle (35)
- # introduce-yourself (1)
- # jobs (4)
- # lsp (20)
- # malli (8)
- # meander (8)
- # nbb (1)
- # off-topic (31)
- # parinfer (9)
- # pathom (3)
- # portal (2)
- # re-frame (20)
- # react (2)
- # reagent (8)
- # releases (1)
- # remote-jobs (4)
- # scittle (2)
- # shadow-cljs (8)
- # slack-help (4)
- # sql (30)
- # squint (3)
- # tools-deps (34)
- # xtdb (21)
Photon is absolutely incredible!! It 10xβd my hammock time. Now even more of my time is spent thinking about what to make rather than how to pull it off.
How many LOC Photon are you at so far?
both, whatever you have
current app is 130 LoC of photon/ui code. I expect that to 3-4x before a first version can be launched
To someone quite invested in a redux and react UI who feels their stack is mature but are curious what photon could bring to them without abandoning what's good about their current architecture, is there a proposition?
e.g. maybe β’ photon + "photon-store" + react instead of β’ photon + photon dom
Or, is it practical to use photon + photon dom to instantiate react components from there, maybe getting rid of redux in the middle?
tbh that's not a battle we want to fight right now
we're very focused on HFQL and declarative crud apps
I'm very interested in HFQL and declarative crud apps, though. π So what I think I must conclude from your answer is: well, we could do lots of things, but the win that we're focusing on currently requires our completing HFQL - what Daniel asks for here would be a mostly uninteresting middleground that wouldn't satisfy the quantum leap we want to put in place before worrying about this kind of compromised integration. Is this in the ballpark?
More specific questions. Are these true? 1. It's easy and quite natural to have photon-dom generate dom that instantiates a react component, passing it props through dom attributes. 2. It's not necessarily clear how, from a React form component, it could interact back to a surrounding photon client context. 3. If we were to integrate photon with redux, we would have to fuzz our way through many puzzling questions. In other words, sprinkling in a few React components in a Photon app might seem ok, but not sharing control of an app in such a way that both libs coexist and cooperate.
The intent of the question is not clear to me β Are you asking on behalf of yourself? a co-worker?
Kind of both, being part of a team, but being more the guy who'd like to reduce toil for the team who writes most of the code using this technology. Obviously I'd like it most if we could go all the way with e.g. photon, but if it's not mature enough UI-wise for example, I know the team feels that then it might be currently very important to stick with mature elements in the frontend stack. I do feel that using React and Redux is both a blessing and a curse, and that we seem to taste our fair share of the curse. This stack seems to necessitate a lot of hand-holding to behave very well. So, I think the intent is mostly to check whether some middle-ground integration might be practical, where the team doesn't lose what they feel is best about React - I suppose it's the rich set of battle-tested components, and how an entire open-source ecosystem is available around it.
I see
We POC'ed react interop in the photon->react direction (so react datepicker) and it works; we don't forsee any technical risk
but your question is more about the frontend architecture β how can we fit cleanly into a Redux mental model to smooth out adoption friction in real world teams that are using react and looking for a bridge?
Yes, if it makes sense
And is this a real concrete question that your team has today?
or a theoretical question
yes, they asked me, even made a small diagram π
Ah and you're using Clojure backend but Typescript/React/Redux frontend today?
Thanks, i forgot that
The questions you're asking will have clear answers in the future, we don't know the answers today, it will require discovery and maybe a quarter of eng time
maybe less, just guessing
Thanks Dustin!
The way I see adoption working today for a team like yours (Clojure users with React frontend) is for internal tools, not your primary app, where you can use Photon (and soon HFQL) natively in a small corner of your business. Once this is de-risked we can grow usage and add complexity, and this will likely involve finding a suitable design partner and working with them as consultants to understand the concrete requirements and develop a custom fitted solution (e.g. Redux adapter)
Does this match how you see this working? (Minus the consulting bits, it will likely be a later stage company who pays for that)
It can also be community sourced, we can provide design guidance for free and merge the best work upstream
Yes, based on your answer, here's what I think would make the most sense: β’ I'd love to explore how to connect the Datomic tx browser to our DB (and expand the tool to more uses: navigate entities and schema, etc., if the tool doesn't already allow it). This would bring some useful knowledge and experience to the table. β’ I'd love to e.g. develop an alternate photon-based UI for a single frontend route (one of our small UIs, say), to start gathering hands-on feedback about what it might mean for us to use photon more directly (at this stage, I understand that it would be much more feasible to use just photon than to use photon + redux + react). We could still serve the same route to users with our normal react frontend tech, so that they wouldn't be affected by any photon-induced problem. Implementing both these strategies, especially the second one, might inform a big deal of our future architectural decisions. For example, we might even decide that there will be no point in keeping e.g. redux and/or react, because ... ... That's why we're asking the questions in this thread, because we're currently thinking about how we'd like to evolve our architecture. The faster we can answer some of these questions for ourselves, the better position we might be in later.
We can certainly support serving a standalone Photon page from the same web server that serves your other pages and http endpoints - we have an example today
I believe @U050CJFRU is serving photon in this configuration
Nice, I think that's very much the way forward for us - let's hope we might make sufficient bandwidth here to actually go ahead with it!