This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-06-30
Channels
- # beginners (23)
- # boot (3)
- # cider (5)
- # clara (12)
- # cljs-dev (15)
- # clojure (18)
- # clojure-spec (24)
- # clojure-uk (23)
- # clojurescript (24)
- # data-science (2)
- # datascript (1)
- # datomic (12)
- # fulcro (51)
- # jobs (1)
- # jobs-discuss (1)
- # leiningen (1)
- # nrepl (1)
- # off-topic (1)
- # onyx (2)
- # re-frame (6)
- # reagent (14)
- # rum (1)
- # shadow-cljs (12)
- # spacemacs (3)
- # specter (1)
- # tools-deps (37)
- # vim (2)
I'm about to embark on a fairly complex data editing backend with many forms, subforms, etc. The app is currently based on Fulcro 2.5.3. I'm curious if you think using the fulcro bootstrap or semantic-ui approach would be better? I'm inclined to use SUI since I've never used it before...
From my reading of the documentation (dom/div :.div.col-sm-2)
and (dom/div {:classes [:$div :$col-sm-2]})
should do the same thing. But for me the first one works while the second doesn't.
I see, the co-located Fulcro CSS, whereas I have the CSS loaded in the standard way, on the index.html page: <link rel="stylesheet" href="css/bootstrap/bootstrap-3.2.0.min.css">
that notation is handy, though, and should probably be adopted into regular DOM…just have not had the time. I particularly like the idea of making it ignore nil, so that you can send in a class that should appear/disappear via an expression:
(dom/div {:classes [(when hidden? :.hidden)]} ...)
I’m pretty sure that made it into the localized dom version, but as keywords (not strings)…not sure which is better for plain dom (keywords or strings), since there is no ambiguity…probably both are fineThanks. I have to use plain dom as am doing a translation from a pre-React ClojureScript SPA.
I doubt that a little overhead will be my greatest concern. Or at any rate not my concern at the moment...
Since your actively using them, I’d be willing to generate a quick snapshot that would support :classes
in regular DOM elements. I don’t think it is terribly hard to add, and I’ve been wanting it myself 🙂
if you’re willing to try it out and let me know of problems that would help me feel better about coding it quickly 😉
Yes of course. I'm going to be using quite a bit of hiccup, as that seems to work fine, and was a requirement for this project. But I know I can use either on a per component basis, and that the differently rendered components compose together perfectly.
Look for “Fulcro 2.5.12” in http://book.fulcrologic.com/#_the_code_render_code_method
@thosmos I'm using Bootstrap 4 via Reactstrap in a very similar scenario. You can use the BS4 classes directly with fulcro's dom fns which is very handy, and reactstrap covers the cases where some js-level implementation is needed (or you could re-implement that yourself, though I haven't found the need to yet)
Reactstrap's coverage of Bootstrap isn't perfect but any issues I've had have been resolved by using Bootstrap classes directly
The one bugbear is that using reactstrap breaks SSR without some sort of stub classes for use server-side being made. You'd have that with SUI too, but not with Fulcro's own Bootstrap3-based stuff.
@thosmos I’m a fan of semantic UI’s CSS. The react implementation is rather large, though I’ve had reasonable luck with the components working. That said, I like having access to clean SSR without running a js engine on the server, so I prefer just using the CSS in my own components for most things. When it comes to a more complex component that has a lot of logic I sometimes punt and make a function that will at least be “ok” with SSR (the cljs side will use some ecosystem js thing, and the clj side will emit some static representation that will largely ignore props and just output something “acceptable” for that initial inactive render). I wanted a autocomplete control recently, and I tried 3 different js versions (including SUI) before just hand-coding my own logic in Fulcro with SUI CSS. I spent like 10 hours trying to get the others to work (the way I wanted), and about 5 getting my own written. This has been my experience a number of times: getting what I want often is faster to just code my own. The CSS is the big time suck when implementing most of these things, and having a pre-written solid CSS library is, IMO, the real important bit. That said, I usually do still try ecosystem stuff when I know it is going to take me hours to write it. Unfortunately, I don’t “give up” and write my own quickly enough sometimes.
The bootstrap namespace in Fulcro is probably going to move to its own library with some other less-known stuff. I don’t have the time to maintain it, and don’t use those bits myself. I wrote them as a proof of concept really, and they should really have their own “maintenance” library. If you’re going to rely on me for maintenance of them, then you will likely be sadly disappointed. That said, there’s nothing to them, so they are “safe” to adopt in that they are a starting point, and you could contribute to maintain them from there.
@oliver.mooney @tony.kay thanks for the great tips! Since this is a backend app SSR is not needed.
I just pushed 2.5.12-SNAPSHOT to clojars with a DOM convenience:
(dom/div :.a {:className "other" :classes [(when hidden "hidden") (if tall :.tall :.short)]} ...)
is now supported on normal DOM elements (client and SSR tested). Waiting on a trial in a large app before officially releasing.the :classes
allows you to more easily use expressions, and will silently drop nil results…it isn’t much different that str
, other than it participates with the keyword shortcuts.
the above tag, assuming (not tall)
and hidden
, would yield CSS classes “a other hidden short” on the output
It technically also allows muliple classes per keyword in :classes, but that is just a side effect of using the same parsing as the props-prefixed classes.
NOTE: This is similar to a feature localized-dom already had, but localized dom localizes the keywords to the component being rendered.
Works fine for me: (dom/div {:classes spacer-classes})
, where spacer-classes [:.div :.col-sm-3]
in the surrounding let form.
I don’t think you’ll run into any problems. I tested the macros, functions, embedded things in dev cards, etc. I think it’s pretty solid.
I’ve been wanting the feature for some time, so thanks for motivating me to finally add it 🙂
@tony.kay if you have a moment, i'd really appreciate a quick sanity check for my modal approach https://clojurians.slack.com/archives/C68M60S4F/p1530299846000275 is this how you are doing modals in semantic ui?
I put modals at the root, so that they are aria compliant …at least that’s why I think it is done that way
At the moment I think I’m actually using SUI react’s component for modals and letting it deal with it 🙂
but doesn't that mean you pull in all of SUI? or is there a way to only pull in one component?
Tried pulling in just a few (shadow-cljs importing dist/commonjs/button). Not a lot of benefit... Just button pulls in a large portion of code ( including ~100kb of lodash).
yeah seems like i'll just make my own modal component in the root
also, thanks for the feedback