Fork me on GitHub
#fulcro
<
2020-05-10
>
tomjkidd01:05:47

Thank you for humoring the idea, and the openness to explore it 🙂

tony.kay01:05:45

It’s an interesting approach, and it might just attract a few re-frame devs to consider that their app could adopt Fulcro for I/O management…and possibly eventually lead them to a more enlightened place 😄

tony.kay01:05:22

I should probably make a YouTube video now, and put it in #announcements

tony.kay04:05:44

@tomjkidd I pushed an update to that repo with a bunch of cleanup, and a bit more nested data.

💯 4
4
fjolne05:05:37

that’s pretty cool! i’ve been playing with the same idea but using Phaser.js as a rendering layer, your repo should be a great reference point

JAtkins06:05:26

Interestingly, as an addition to fulcro for my app I accidentally designed a graph reducer that functions very much like reframe. I think a combination of the two approaches to ui management is really nice to keep your mutations in check (w.r.t fulcro side) and keep a nice data/io model from fulcro.

folcon10:05:37

I think this might be really useful =)… I understand re-frame quite well, so something in the middle might be a great way of framing it and clearly understanding/articulating the difference of the two approaches =)…

tony.kay04:05:46

@holyjak 0.0.4-SNAPSHOT of RAD with your changes. @currentoor yours as well

❤️ 8
👍 8
tony.kay04:05:55

So, next time you’re trying to talk a Reframer into trying Fulcro, maybe this will help : https://www.youtube.com/watch?v=ng-wxe0PBEg&amp;feature=youtu.be

16
lilactown21:05:33

this is REALLY cool

lilactown21:05:57

we've been talking about adopting pathom at work, but we currently have a mix of reagent/re-frame and helix code.

lilactown21:05:10

we're looking for something like fulcro's normalizing data layer, but more a la carte

lilactown21:05:06

this gives me some hope that we could perhaps leverage some key parts of fulcro, and use them in the app using either React Hooks or re-frame subscriptions

lilactown21:05:54

is this something that you would ever think of actively supporting? e.g. splitting out fulcro-data and fulcro-ui into separate packages/

tony.kay22:05:03

no need: cljs only includes the things you use. Tree shaking will make it so you only get what you use.

tony.kay22:05:48

so no, will not be doing that…I am open to PRs that fix any bugs in headless operation, if you find those…but it should be totally usable as is without any real bloat.

tomjkidd21:05:48

@U4YGF4NGM If you are interested in this functionality, I created a namespace and an api to allow for pure operations using the concepts involved: https://github.com/tomjkidd/hello-shadow/blob/febdfffc789d61cc4acfa025b542a83297510d72/src/app/graph.cljs I also created a couple of tests to sketch the idea: https://github.com/tomjkidd/hello-shadow/blob/febdfffc789d61cc4acfa025b542a83297510d72/src/app/graph_tests.cljs NOTE: This repo is throwaway code, but I am trying to capture useful experimentation.

tomjkidd21:05:04

I am still tinkering with this, because I’m trying to make sure that everything I need to rely on is achievable, and then slowly add more dependence on fulcro as my team is more comfortable with the serious weight it is pulling

Daouda14:05:22

I am using this code to have a multiselect working with code? When :`multiple false` I got a normal dropdown of single select, but when :multiple true no more dropdown . Can anyone help to figure out why?

(dom/div {:className "form-group"}
          (dom/label nil "Select")
          (apply (partial
                   dom/select {:className "form-control"
                               :multiple  true})
                 (for [option options]
                   (dom/option {:value option} options))))

fjolne15:05:42

it’s more of a general HTML/DOM question rather than about Fulcro, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/select in your case, i’m not sure why you pass the whole options list as a child of a single option, you probably meant something like

(dom/div {:className "form-group"}
        (dom/label nil "Select")
        (dom/select {:className "form-control"
                     :multiple  true}
          (for [option options]
            (dom/option {:value option}
              (:text option)))))
where options is a list of maps with :value and :text keys

fjolne15:05:58

ah, you meant the dropdown behaviour itself: <select multiple> just works like that in browsers, if you’re looking for dropdown with multiple options then it’s worth considering third-party react components there’re Fulcro wrappers for Semantic UI, but any React lib will do https://github.com/fulcrologic/semantic-ui-wrapper

👍 4
Daouda16:05:46

> in your case, i’m not sure why you pass the whole `options` I made a typo when writing my on slack 😄

Daouda16:05:29

Thank you very much @UDQ2UEPMY

🎉 4
Daouda19:05:21

Is there any problem to use project.clj instead of deps.edn ? I am using fulcro 3 and shadow-cljs compiler.

fjolne21:05:51

should be enough to set shadow config to use leiningen instead of deps. didn’t try it myself, but can’t think of any problems

dvingo17:05:23

i have a state machine where i'd like to run a global "post-handler" on any event. is there any way to hook that into the state machine? i'm currently using a wrapper: ::sm/handler (global-post-action (fn [env] actual-handler)) where global-post-action returns a function that calls the actual function first and then applies its own update to env. basically the middleware pattern. this works but it requires me to wrap every handler with this helper.

tony.kay04:05:13

Well, off the top of my head I can think of a few approaches: 1. Invent your own format for the UISM map and a function that will transform that into UISM’s standard. You could make your input much less verbose, and easily add such a feature. 2. You could implement your own trigger! and trigger mutation, and augment the internal functionality while using the pre-written parts that you don’t want to change. 3. You could make a plugin for an alternate transaction processor that supports the idea of something that gets called after every mutation (as a general extension) and leverage that to selectively do your post action on trigger mutations.

tony.kay04:05:23

Personally I’d go with (1)

dvingo20:05:50

Thanks for the follow-up! I'll ponder the options..

tony.kay20:05:49

I have, in fact, in my own work done (1). The format in UISM is accurate and simple, but isn’t optimal for ease. I have not pushed my “ease” stuff into OSS because I’m not sure “my optimal” is an overall good match for everyone. But just doing things like make a function to generate a state that accepts a sequence of event maps, that themselves can be generated by an event function cleans readability up a lot (state :state/x (event :event/y do-y) (event :event/z do-z))

tony.kay20:05:24

throw in the target state on that event function and it gets even cleaner (assuming the event has a single target state)

dvingo20:05:11

yea it's always tricky balancing one use case vs the generel. But, it's nice that the format is just a map so we can try out some different sugar on top of it.

tony.kay20:05:12

and things like defining a macro like defevent that can be used to both generate the section of UISM’s map, and also be used as a trigger:

(defevent bam! :event/bam (fn [uism-env] ... handler ....))

(defstatemachine machine
  {::uism/states 
   {...
    (state :state/whatever :events bam!) ; auto-detects the `deftype`'d value and extracts the map
   }})

...

(bam! app machine-id event-data) ;; short-hand for (uism/trigger! app machine-id :event/bam event-data)

tony.kay20:05:27

that gives you code navigation, which is super handy in larger code bases…and your generated Fn handler in the type could auto-detect if it is passed an app or env, so it could be used inside of event handlers or the main app

tony.kay23:05:05

Fulcro 3.2.5 is on Clojars. I changed the sync transact stuff back to being strictly component local (I had added in a delayed global refresh, but that was just a mistake). I undid the integration of it with mutation helpers, so this should be a non-breaking change. I also added new mutation helpers with !! suffixes that use it for convenience. Any explicit uses of transact!! in your code should consider this a potential breaking change (if the parent was displaying data derived from the child, then the parent will now fail to refresh). You can use app/schedule-render! to manually schedule a full render for such situations.

murtaza5208:05:38

I assume fulcro 3.2.6 snapshot contains the above changes ?