OK, so the current websocket support is very ugly, and I’ve made the time to start re-working it. There’s a new (very simple) demo at https://github.com/fulcrologic/websockets2-demo. I’ll probably be porting the formal websockets-demo to this soon, but the new support is much cleaner, and will be much simpler to tune up to be a really nice API. At the moment, it should be considered alpha quality, and it is currently only available in 2.2.0-SNAPSHOT on clojars. The nicest parts: It’s sooo much easier to use. Easy server setup is just:

(defn build-easy-server [path]
  (easy/make-fulcro-server
    :config-path path
    :components {:websockets       (fulcro.websockets/make-websockets (fulcro.server/fulcro-parser))
                 :ws-adapter          (fulcro.websockets/make-easy-server-adapter)}))

(new-fulcro-client
                ; replace the default remote with websockets
                :networking {:remote (fw/make-websocket-networking "/chsk"
                                       :push-handler push-handler
                                       :state-callback state-callback)})

(defrecord Middleware [ring-stack websockets]
  component/Lifecycle
  (start [this]
    (assoc this :ring-stack
                (-> (not-found-handler)
                  (fulcro.websockets/wrap-api websockets)
                  (wrap-keyword-params) ;required
                  (wrap-params) ; required
                 ...
                  (wrap-not-modified)
                  (wrap-gzip))))
  (stop [this]))

Developer’s guide updated with new logging and websocket info.

2.2.0-SNAPSHOT is on clojars

Is there a way to configure co-css by props?🙂

by props?

no, because the CSS has to be available when things start

I think it might be possible, now that FUlcro controls the rendering pipeline, to make dynamic updates during rendering possible, but I’ve not researched how I might go about it

you can embed data (e.g. values from atoms), and then re-up your CSS to get dynamic effects

@eric.shao what you mean by co-css by props? give extra css via props?

you could hack it pretty easily, though, now that I think about it.

I really didn't understand the question

if it is about adding more css via props, I have some helpers to do that, they are easy to write

He’s asking if you can do this:

(defsc [this props]
  {:css [[:.x {:background-color (:color props)}]]} ...)

I mean, not exactly extra css, I prefer to provide extra classes, and then allow those classes to be added via props

ah

that's different

I usually do that indirectly

The answer at the moment is no, but I’ve kinda wanted something similar (props or computed)…and I think it would be possible with a tweak to the API.

but for details like this, if it needs to be dynamic, we can just use :style

that’s true

but what if you wanted to load style info into your app state from a server configuration?

you could use styles, but it would be nice if you could inject state data into the css

well, if you need that level of configuration, just do garden, hehe

it’s very true…the fulcro-css library is very tiny

we could provide some helpers just to do proper namespacing

but otherwise seems out of fulcro-css scope IMO

I think it is perfectly possible to make it work like get-query: works on a class or instance

that way the static “startup” would be there, and from there dynamic behavior could be possible.

I like it, I just don’t have the time to code it at the moment 🙂

are you suggesting we might end up with one (or many) css class per instance?

that is already there…what do you mean?

I’m suggesting that the css method could be real code that could use props/computed (if available).

now we a relation: many css per fulcro component

but to do what you are saying, we might end up with a different set of classes, one set of class per instance

to be able to customize with that instance props

I don’t understand what you’re saying

for example, let's get your code

(defsc MyItem [this props]
  {:css [[:.x {:background-color (:color props)}]]} ...)

say I have one component with {:color "red"}, and other with {:color "blue"}

I can't provide a single css class that will target both

they would have to be different classes, right?

(defsc X [this {:keys [a]} {:keys [c]} {:keys [resulting-class]}]
  {:css (fn []  [[:.resulting-class {:color (or a "black") :background-color (or c "white")}]])}
 (dom/div #js {:className resulting-class} ...))

yeah, you can't share those dynamic classes

correct, in that case you would not be able to pull in the classes from X without them being the “default” (static) version

or can you?

the classname isn’t changing

but what that class will contain? what color will be there?

the one from the last time the styles were pulled from X itself

what if I have 2 diferent instances with differnet colors

the class name will be the same

then you’ve coded a bad thing 🙂

to-many things should not do this, for sure

that's what I'm saying, if you allow that I'll assume this is dynamic

doesn't seem to worth it, a simple :style can solve this very nicely

agreed…and atom-based globals for general styles (or shared props that go to style attrs)

ok, thanks for talking through that…now we have a good answer to the question…now f only we had time to blog about it 🙂

no problem, always good to have those chats

it's kind fun, someone asks something, and we starting talking all over it (while the questioner is away), it's not the first time 🙂

chris@chris-Latitude-E6420 ~/IdeaProjects/websockets2-demo $ npm install --save-dev shadow-cljs ▀ ╢░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░╟

WARN engine [email protected]: wanted: {"node":">=6.0.0"} (current: {"node":"4.2.6","npm":"3.5.2"})

https://nodejs.org/en/download/package-manager/#debian-and-ubuntu-based-linux-distributions

defintely upgrade 😛

Anyone out there that runs Linux? Seems like I'm going to need to get latest node to run.

Thanks @thheller

I'm running the 9.x version on debian

Or maybe its a slow network (timeout getting resource) problem from my end, and I should just try again..?