Fork me on GitHub

@jonas I haven't done any testing at all - but in theory it should work. You would have to run the bundler on your splits


experience reports welcome


7 years later, this runs great on a mobile device! 😃 cljs (

🙂 12

I need an ordered set for clojurescript, which should I use?


(something that preserves the insert order)


sorted-set or perhaps sorted-set-by ?


This is value order, not insertion order.


oops, I misread the question.


I could use a regular map with the values at the key and the count (as I insert them) as the value


If your use-case doesn't require frequent iteration over the collection in the insertion order, then it should be fine.


Alternatively, you could port something like to ClojureScript.


next summer perhaps 😉


You can also take a look at - it was written for DataScript


damnit, nevermind. facepalm


I'm going to get a coffee now and log off the interwebs for a while 😄


this may not be the best channel, but I wanted to kick this off as a starting point. I've been looking at and found it pretty interesting to potentially kick the tires with. digging deeper, I found with a nice discussion that @yogthos and @thheller had. this is a fairly old thread now - is there any interesting work going on in the space of Svelte's goals?


which now lives in and is used by the shadow-cljs UI


no react anywhere 😛


works quite well .. just not much time to work on it

👍 3

I’ve been working on a library called Similar to svelte, the ui framework reads your code(via macros) and can figure out how a child component’s properties depend on their parent’s component properties. It’s still experimental, but feels pretty good. Your code ends up being fairly terse. Here’s a simple todo app:

;; Display a single todo item
(defui todo-item [ & {:keys [todo]}]
   (translate 5 5
               (fn [[mx my]]
                 [[:delete $todo]])
   (translate 10 4
              (basic/checkbox :checked? (:complete? todo)))
   (spacer 10 0)
   (basic/textarea :text (:description todo))))

  (run-ui #'todo-item {:todo
                       {:complete? false
                        :description "fix me"}}))

(defeffect ::add-todo [$todos next-todo-text]
  (dispatch! :update $todos #(conj % {:description next-todo-text
                                      :complete? false})))

;; Display a list of `todo-item`s stacked vertically
;; Add 5px of spacing between `todo-item`s
(defui todo-list [ & {:keys [todos next-todo-text]}]
    (basic/button :text "Add Todo"
                  :on-click (fn []
                              [[::add-todo $todos next-todo-text]
                               [:set $next-todo-text ""]]))
    (translate 10 10
               (basic/textarea :text next-todo-text)))
    (spacer 0 5)
    (for [todo todos]
      (todo-item :todo todo)))))

  (run-ui #'todo-list {:todos
                       [{:complete? false
                         :description "first"}
                        {:complete? false
                         :description "second"}
                        {:complete? true
                         :description "third"}]}))

Michaël Salihi15:06:09

I wonder if we can toying with CLJS and Svelte with Svelte-preprocess

Michaël Salihi15:06:38

I'm sure @thheller is going to find something mindblowing again 🙂


happy to look at other things for inspiration but I have no intention of actually using svelte 😉

👍 3
Michaël Salihi17:06:40

Yes, I remember read you about Svelte on some Clojureverse post.


membrane looks cool. Yeah, I don't have any intention of using it either - I think we're mostly already there with cljs and existing libraries, and by mostly I mean all the way except for getting a satisfying user experience around it, everything tied together - work like membrane and arborist


I think there’s still a huge amount of improvement available in the UI library design space.


Yeah. I'm working on a direct port of tailwind (given another convo) to cljc to start helping improve the availability of this type of tooling.


I’ve recently learned that input type=number has some odd behaviour that does not gel well with e.g. Reagent. For example, since 42e3 is a valid js number, you are free to enter that into your input. However, even if e4e2e3e is not a valid js number, you are allowed to put it into your input field. Since it’s not a valid js number, the on-change function that you are normally relying on won’t fire, so you’ll end up with a browser state that has e4e2e3e and an atom state that doesn’t. (That’s my own reasoning, based on what I’ve witnessed.) Is there some general wisdom somewhere about using input type=number regarding such gotchas as the above somewhere on the internet? I tried googling for it, but didn’t find what I was looking for. Specifically, it seems to me that using input type=text instead and rolling your own validation (and whatever else behavior you need) seems to be the more appropriate solution in general, as you’ll be more in control of what happens and how it should look.


(I prefer using whatever is provided directly by HTML for a number of reasons, such as A11Y, hand-rolled solutions not covering corner cases that the HTML implementers already took care of, the extra upkeep that comes with rolling your own solution and so on. So I’m kind of sad about my current conclusion.)


Number inputs are tricky also across different browsers and mobile. I remember a recent article that advocated type=text and using a pattern to do things like bringing up the number keyboard on mobile.


input type=number also takes you to even deeper levels of hell when you need to support multiple locales. Maybe the situation has improved since 3-4 years ago, but back then, we 100% punted on this, and we implemented our own numeric-entry UI. We did this in html/JS and never looked back. (we didn't implement custom mobile-OS keyboards, which I suppose is possible, but we have a html/JS app and use Cordova to run it on multiple mobile OSs)


The locale problem was something goofy like... say you were in a locale that uses a comma , to be a decimal separator instead of the .


When you pre-populated an <input type="number" with a number like 1,23 and you were in such a locale, this was fine... BUT after a user manipulates the value and you need to pull it out of the <input, it would get a non-locale copy of the value (like, it'd convert it to 1.23 even though).


Note: I might have this description exactly backwards... like, maybe it was you had to always SET the value with a non-locale-specific version (like 1.23) but when you would take the value out, then it'd be formatted 1,23 Anyhoo --- it was utter madness. And it was not always consistent across iOS, Android, and Chrome.


BTW - with our approach, we didn't even use ANY html input box. We just styled up something that looks like a textbox using plain old divs, and then pull up a keypad entry widget (of our own creation) elsewhere on the screen.


@UHL84CDTP crikey, that’s some endeavour you went through! I wasn’t aware of the decimal issue, that sounds horrible.


It’s too bad that things are not more stable and standardized in the world of HTML. Yet, at least. We can hope for a better future 🙂


Thanks for sharing your tale!


I'mhaving a problem getting a very basic reagent app to work. My deps.edn

{:deps {com.bhauman/figwheel-main {:mvn/version "0.2.8"}
        com.bhauman/rebel-readline-cljs {:mvn/version "0.1.4"}
        reagent {:mvn/version "1.0.0-alpha2"}}
 :paths ["src" "target" "resources"]}
My demo.cljs.edn
^{:css-dirs ["resources/public/css"]}
{:main todo-demo.main}
My folder structure looks like this:
     ├── demo.cljs.edn                                                                                   
     ├── deps.edn                                                                                        
     ├── resources                                                                                       
     │   └── public                                                                                      
     │       └── index.html                                                                              
     ├── src                                                                                             
     │   └── todo_demo                                                                                   
     │       └── main.cljs   
My main.cljs:
(ns todo-demo.main
  (:require [reagent.core :as r]
            [reagent.dom :as rdom]))

(defn title []
   [:p "Hello, World"]])

(defn app []

(defn main []
  (rdom/render [app] (js/document.getElementById "app")))
I run it with
$ clj -m figwheel.main -m --build demo --repl
But I can't get it to display Hello World in a div. My index.html:

    <!-- this refers to resources/public/css/style.css -->
    <link href="css/style.css" rel="stylesheet" type="text/css">
    <div id="app"></div>
	<!-- this refers to target/public/cljs-out/cruel-main.js -->
    <script src="cljs-out/demo-main.js"></script>
Have I maybe missed what I need to call the main function for it to be called? I can do this at the repl from the docs:
(def app-element (js/document.getElementById "app"))
(set! (.-innerHTML app-element) "Hello, World!")
And I get Hello, World on the page.


@qmstuart if you open the devtools console in your browser what does it say?


This is the console output


@qmstuart you are not calling the main fn anywhere. add <script>todo_demo.main.main();</script> in your html

👍 8

That did it!! Thank you 😄

👍 8

    <!-- this refers to resources/public/css/style.css -->
    <link href="css/style.css" rel="stylesheet" type="text/css">
    <div id="app"></div>
	<!-- this refers to target/public/cljs-out/cruel-main.js -->
    <script src="cljs-out/cruel-main.js"></script>


the tutorial doesn’t encapsulate start in a main function


Is there a way to read the cljs compiler options during macro expansion?


careful with this though. might get you into trouble with caching.


it looks like versions after 1.10.520 broke IE


the new one spits out a const eb in a and IE 11 does not support that


no CLJS code outputs const anywhere. likely one of your JS dependencies?


@thheller I don't think my dependencies are getting minified depending on my clojurescript version but I'll try to reproduce it in a clean repo


@thheller, here's a repro way:

lein new figwheel repro
lein cljsbuild once min


in the file you'll see function ha(a){const b=[];let c=0;for(const d in a)b[c++]=d;return b}


@mengu that output needs to be bundled


run it with :pretty-print true :pseudo-names true in your compiler options to see where that is coming from


actually I take that back


ah wait ... it probably is from the closure library


and when I set the version as 1.10.520, no consts of any kind


so try :language-out :es3 in your compiler options


that worked


looks like I've missed that change in the release notes


apologies for taking your time @thheller & @bhauman


super easy to miss


thanks again 🙂


What's my option(s) for REBL (or alike) in ClojureScript? Does the official cognitect REBL work with Cljs?


I think shadow-cljs inspect is moving towards that


I think a remote REBL makes a lot of sense. if I ever take a sabbatical it will be one of the projects I try and work on 😄

💯 3

is there a way to say, “run this at the end of the current tick?”


I don’t want to use setTimeout/rAF/promises because I want to do the work in the current tick


ah, actually Promise.resolve might do what I want