I'd just use the built-in react state management hooks

use-state/use-reducer/use-context/use-ref

I use refx for global state , use-state for local state management, and react-hook-form for reducing the use of state management.

Personally I’ve really liked offloading (almost) all global state to tanstack-query, https://tkdodo.eu/blog/practical-react-query is a really good resource if you want to go down that path (and I’d definitely recommend it)

I've been combining fulcro for state management + transaction management with helix and subscriptions for UI updates. example https://github.com/matterandvoid-space/todomvc-fulcro-subscriptions fulcro has a "remote" abstraction which is where features similar to react query are implemented for example - retry failed https://github.com/fulcrologic/fulcro/blob/71ed79c650222567ac4a566513365a95f12657e3/src/main/com/fulcrologic/fulcro/networking/tenacious_remote.cljs

I'm curious though, @U7KPK060K what benefits do you get from using cljs vs js/typescript with your stack? any tradeoffs you lose from doing so? in short: why not just use js/typescript?

@U051V5LLP @U7KPK060K I am curious too. At the moment I am using react-query, react-table and nivo charts on an app and I feel I am not gaining a lot using Clojurescript. I wanted to stick with it to see if I have an aha moment this is what makes it so much better

I can vouch that typescript is so so so good on front-end

@U02N27RK69K do you normally write typescript components to be used with Clojurescript via interop? Or you just use vite/next depending on the app you’re building?

Sometimes the whole team knows clojure and if the frontend is in clojurescript it’s easier to stick to one language for frontend and back, but to be honest if there are people in the team who know or are happy to learn typescript I think I prefer that over cljs these days

nah, I don't typically use clojurescript w/ typescript. I barely use cljs, really

I think the big win is the fact that there a million front-end APIs, and front-ends end up very complicated, and so having types to guide you is a huge help. I'm sure I'd choose cljs over just js without typescript

If you are heavily using js libs and don’t like all the interop squint is quite an interesting concept, you can write code that interacts with js libraries pretty seamlessly, here’s a quick example I was playing around with using react query and graphql subscriptions https://github.com/armincerf/squint-chat/blob/main/src/Comments.cljs

squint is so great! (full disclosure: I work on squint)

Yeah I love squint, contributed to it, it’s just too cutting edge for production use on the particular app I am making

I can definitely understand that

I'm really excited with squint, last time I checked I just missed repl support, but is super promising

cherry is really cool, too, fwiw

one of its sister projects

also I can't recommend enough just pairing with someone who knows TypeScript to get up to speed. it helps so much

thanks for your replies! It's good to hear about different setups. If you're sending json over the wire, talking to http servers I'm not sure anymore that cljs is the right choice. I still use it when I can send transit over the wire and have a pathom backend though.

Exactly thanks for all the inputs, I will spend some time thinking and reading about everything said in this thread 😄

@UMMMKKADU would love to hear your conclusion when you are ready

I've been using refx for a quite while for pet projects, I'm really keen to try it in production and if anything goes super wrong do a personal fork or so, my only fear is the lack of useful tools like https://github.com/day8/re-frame-10x or https://github.com/flexsurfer/re-frisk, but you always can use the repl inspection or a https://github.com/rafaeldelboni/helix-refx-playground/blob/main/src/app/core.cljs#L72 on the db atom 😬 But I will still discuss with my team, @U02N27RK69K’s suggestion of using react default tools are appealing for me as well.