This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (6)
- # announcements (2)
- # babashka (8)
- # beginners (121)
- # calva (7)
- # cider (7)
- # clj-kondo (25)
- # clojure (167)
- # clojure-android (1)
- # clojure-italy (1)
- # clojure-sweden (1)
- # clojuredesign-podcast (2)
- # clojurescript (11)
- # community-development (33)
- # cursive (23)
- # data-science (1)
- # datascript (11)
- # datomic (7)
- # emacs (12)
- # events (1)
- # fulcro (15)
- # graalvm (3)
- # hoplon (1)
- # instaparse (1)
- # malli (12)
- # off-topic (1)
- # planck (3)
- # re-frame (5)
- # shadow-cljs (61)
- # test-check (2)
Fulcro 3.1.2 released. Adds a string buffered input wrapper that makes it easier to make custom HTML5 inputs that use “real” data types (like keywords, ints, dates) in the model, even though the input itself only supports strings. It helps particularly with the tricky issue of the strings not always being valid values in the real data type domain (and sets the domain value to nil in that case).
Trying to get a feel for Fulcro, I’ve used re-frame+Reagent in the past, why would I want to switch to Fulcro?
Yes I’ve read some of the book and have gotten through 5 of the videos on YouTube Tony put together. I’m trying to understand the trade-offs though of using Fulcro versus re-frame+Reagent, hx, uix, etc
For my part I'm not a fan of listeners, events for writing UI code. More maintainable to program to a model (app state) and let the UI take care of itself.
@U0D5RN0S1 what do you mean listeners?
Where there are subscriptions. Your code subscribes to be told about certain events. I was a Java Swing programmer for a long time, then JavaFX. There's many different expressions used, but it all looks and feels like listeners to me.
So futures, promises, reactive programming, callbacks - all feel like listeners of some sort, and all result in messy, hard to understand code if they are the mainstay of the programming model.
@U0D5RN0S1 what are your thoughts on hx/uix/other alternatives?
Obviously with Fulcro the UI is listening to the app state. But the application programmer only needs to deal with app state. If those alternatives make it so the application programmer doesn't have to deal with listeners, then the next challenge: do they have something as powerful as EQL for querying?
@U3A61KK5E did you watch https://youtu.be/PMbGhgVf9Do
I'm evaluating Fulcro for the first week and here is my 2 cents. The whole front-end craft is infinite fractal of big complexities as well as small complications. What I see finishing reading
Getting started chapter is that all hard architectural decisions are made for me. I mean things I'm aware of, but don't touch in real projects because of budget/timing considerations (e.g. query co-location & composition). With Fulcro, I expect to get rid of ad-hoc architectures while still dealing with important micro-details like this one: https://github.com/fulcro-legacy/fulcro-incubator#flicker-free-io-progress-and-errors.
Also, here are more things to consider: https://docs.google.com/spreadsheets/d/1kBJLjN2Z1AFJM4W8S7YTn0PS_drzqtIMY5siSIZ5OWI/edit#gid=0 (from Fulcro website)
@UDQ2UEPMY thanks for that, I'll take a watch tonight. Been looking for someones experience with using it in production successfully