This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (419)
- # aleph (8)
- # aws (6)
- # beginners (148)
- # boot (9)
- # cider (24)
- # cljs-dev (37)
- # cljsjs (8)
- # clojure (134)
- # clojure-android (6)
- # clojure-brasil (15)
- # clojure-dev (8)
- # clojure-dusseldorf (2)
- # clojure-greece (67)
- # clojure-italy (8)
- # clojure-japan (3)
- # clojure-russia (3)
- # clojure-spec (8)
- # clojure-uk (13)
- # clojurescript (54)
- # clojurex (6)
- # cursive (5)
- # data-science (12)
- # datomic (15)
- # defnpodcast (11)
- # emacs (25)
- # fulcro (95)
- # graphql (3)
- # lein-figwheel (1)
- # leiningen (27)
- # luminus (1)
- # lumo (6)
- # mount (2)
- # off-topic (112)
- # om (3)
- # onyx (24)
- # perun (3)
- # re-frame (20)
- # reagent (1)
- # reitit (2)
- # ring-swagger (13)
- # rum (10)
- # shadow-cljs (45)
- # spacemacs (24)
- # sql (2)
- # unrepl (78)
- # yada (1)
has anyone confirmed that react v16 doesn’t break the
bindings the component
@thheller didn't had a chance to try, but my guess is that it would only break with the new async rendering (that comes disabled by default as far as I know), are you trying it? I'm also curious about how that goes
I’m probably not going to use
fulcro as I really dislike the protocols and “macro infection” style from om.next
so I didn’t get that far in my tests but some tests I did in the past didn’t work too well with
@thheller what are you going to use instead ? protocols & macros aside, fronend & backend complete story + normalized db + a lot of complexity that just isn't there. Could not find anything close to fulcro for my projects.
I can relate to pain with macros and protocols, but I think Om.next/Fulcro does a good usage of then, it enables the components to know a lot about themselves without having to spread logic across the entire project, I don't bother at all with then (although I was reluctant to start using macros like
defsc, in the end I accepted they are better than the other option), and like @claudiu said, I can't find anything that gets even close to the complete story that removes so much complexity out of my code
I should clarify: I’m probably still going to use parts of fulcro. I pretty much like everything except the react interop
@thheller I’m moving towards a form of defsc that makes the magic optional (and am liking it better). I need to keep defui around in order to make porting from Om next easy, since there are a lot of people that use Fulcro, and many that end up coming in from Om next with existing code.
In fact, the new defsc is done, and I’ve just been updating the documentation…a very time-consuming task because there is so much 😉
I’d be interested in hearing any proposals on how the react interop could be better.
@tony.kay I’m just super picky about macros and the code they generate so really don’t listen to me.
I had hoped it would be easier to just pick the parts I wanted but I guess thats not the goal of fulcro at all
Yeah, the react generation isn’t just react…it is critical to the entire model for simplification
data model + top-level transactions as data + UI refresh via reasoning about data + server interaction via that same data
The server stuff is easy to swap out however you want, but the client has a very intentional design where all the parts fit together
yeah that is probably a good thing. I’m just not ready to let go of the stuff I already do in my own apps.
in other words, what need do you have? Perhaps you’re missing something grander by holding onto something old
perhaps I’m insane and have crap 🙂 I’m always interested in exploring that question 😜
ah…implementation detail. Not tied to it at all. Inherited it from Om Next. Would be happy to change it, though I don’t want globals (more than one app on a page)
(before 2.0, I had no control over it…so I’ve not been able to even question it until now)
ok, that’s fair. Off the top of my head, I think we’re safe there, but I do agree that async (or even webworkers) could have impacts.
they are only used during the react element generators, which should be pure functions that contain no async ever.
all of the bindings are also intended to be private, so UI should not be able to derive values from them that could screw up later (say on a lifecycle thing)
things like the reconciler are singletons, so even if you did close over it, it would not hurt anything. All of the internal things that change are in atoms, so you would never be “stale”
Yeah, they have this to say in the docs “If you want your application to be stable, don’t use context. It is an experimental API and it is likely to break in future releases of React. ”
but its essentially just passing down one variable (eg. the reconciler) automatically without having to pass it to props every time
well, good to know it is there. If it causes any problems I’ll at least be aware of the alternative.
some of it is still kind of a mess (the application startup is a hair ball, and the server stuff evolved in too ad-hoc a manner)
easy server is great for getting started quick, but not really idea overall for production. The newer modular server stuff is probably overkill. It was intended to make full-stack libraries easier to build because they’d have a target on the server. I’m still analyzing if that makes sense. I’ve been leaning towards beefing up the docs around “building your own server” with
handle-api-request, and documenting easy server as an early dev tool.
well, I’m working on this like 12 hours a day. Point them out 🙂 if they aren’t part of the core user-visible story, I’m game.
I will … still exploring. It just my
:advanced problem radar going off too early probably
There is one very big thing I think is a real crappy thing (got from Om next): https://github.com/fulcrologic/fulcro/issues/67
that one sets on warning bells every time I see it. Definitely going to fix that gem soon
The problem is the static protocol implementations. If you make them, but never call them via the class, then advanced optimization removes them.
2. If your dev environment refreshes namespaces (via tools-ns), it can “undo” the hack
ah so the issue is that closure is not smart enough to figure out the fns are actually called
quick-n-dirty is to emit a try/catch with static calls to them (top-level code that just silently runs in namespace)
makes code size bigger, but I like that better than the compiler hack. better fix is to figure out how to emit code that doesn’t get optimized away
https://developers.google.com/closure/compiler/docs/limitations this page explains what is wrong (under flattening, and statics)
to support SSR and other things, we never call
initial-state on the class…we use helpers that turn it into a variable. Boom.
I’m also game to move away from the protocols. I mean,
defsc is already a move in that direction. It makes it so people are no longer writing protocols. At some point it would be possible to make it so that protocols are not actually involved at all.
in practice we’re using static protocols for everything important, and when mixed with SSR you need a helper wrapper anyway, and never end up even directly using the protocol. So, in practice, it’s kinda silly
that said, that kind of transition needs to be made a bit more slowly. I have users that would not like things breaking in big ways with their source code. Trying to keep it all scriptable for 2.0…just some renames.
But something new that we can transition towards is totally doable in the near future.
I’ll try to finish the “fulcro-light”
defui replacement I started. when it works that might be an option