Fork me on GitHub
#clojurescript
<
2019-01-25
>
john00:01:10

Question about artifact size: there's always been a strong sentiment in the js world that minimizing artifact size is super important... Does it still matter that much in 2019? If lower level libs are cached with a long ttl, isn't it not that big a deal, for most apps?

lilactown17:01:29

still v important IMO

lilactown17:01:01

if only because the requirements of our apps will continue to rise, which will encourage us to package up more to the browser

lilactown17:01:01

for example, wait until people are packaging up whole runtimes / etc. in wasm and shipping them over grandpa’s AOL connection 😬

john17:01:54

But once it's cached... The first time I open photoshop in my browser, I may have a few second delay, sure

john17:01:58

But then it's cached

lilactown17:01:01

that’s fine for photoshop, which is a power user application. but what about a marketing / promo site? or a health insurance app for viewing my claims?

lilactown17:01:44

it’s also a fact that we don’t care because we’re in a place with good connection, on our laptops. many people interact with the internet in very different conditions

lilactown17:01:36

think of developing countries, or even many places in USA who don’t have good fiber and have to rely on 3G / Satellite / etc.

lilactown17:01:45

obviously this is going to depend on your use case. I work in health care so I have to make sure that grandpa can see their medicare stuff without fuss. If you’re building a blockchain yogurt app for millennials or a photoshop-in-the-cloud for professionals, you might not need to worry quite as much

lilactown17:01:01

but still, there will always be an improvement in UX by improving the time-to-load

john18:01:08

So, let's say a meg or two. Is it exorbitant for a user on a 3G connection to have to download a meg the first time they visit my promo site?

lilactown18:01:36

yes, I have already left and am on instagram if a site takes more than a couple seconds to load 🙂

john18:01:03

Yeah, that's the main objective evidence I've heard.. some study proved that every extra second your site takes to load, some surprising number of users drop off.

john18:01:28

But, something tells me, that study is mostly talking about the kind of clickbait that goes in AMP pages

john18:01:12

clickbait AMP pages need to be very lightweight, cause that crowd barely conscious when doing their browsing.

lilactown18:01:37

I mean, I definitely notice the pattern in my own use. especially on my phone

john18:01:55

they really don't care about what they're looking at... But for most use-cases, I'm not sure if people are so careless

lilactown18:01:28

if I’m on my laptop, a slow loading tab is nbd. if I’m on my phone, I get pretty frustrated after waiting 3 seconds. if I don’t really want to see this site, I’ll move on in my browsing

john18:01:13

Not if you've gotta check claims in a health insurance app, right? It's only the most useless of click-baity things that our attention is so easily drawn away from

john18:01:49

3 seconds does kinda suck though, agreed

lilactown18:01:03

true, we were talking about promo sites. also things like marketing sites, news articles, etc.

lilactown18:01:21

if my blog takes 3+ seconds to load that sucks 😕

john18:01:47

how many of us are building those things though? Most web devs aren't in that same box

lilactown18:01:07

for things like claims in a health insurance app, it’s more of an ethical concern that you are only servicing a certain section of the population: people with fast computers on good networks

lilactown18:01:21

there are multiple concerns

john18:01:22

We could say there's an ethical problem with a downloadable health app too.. 10 megs instead of 20. But that's just not a thing.

lilactown18:01:14

it is a thing! if my app takes up 300mb, or only works on latest iOS, etc. same problem

lilactown18:01:01

obviously there are diminishing returns on download size. the NYT pays way more attention and spends way more resources on reducing page load than we do on our health care site

john18:01:19

Maybe a little... Not a huge thing. But you've persuaded me slightly back into the fold 😉

john18:01:37

Yeah, for NYT, I get it

lilactown18:01:24

luckily the tooling is good enough today that just by using CLJS with optimizations and gzipping, you get a long way

lilactown18:01:31

also, server rendering more

lilactown18:01:05

spending more or less than that is going to depend on your use case

lilactown18:01:16

glad I could help 😜 good chat!

👍 5
hoopes02:01:58

is there a cljs equivalent of https://momentjs.com/docs/#/displaying/calendar-time/ (like iso8601 date string to Yesterday at 2:30) or should i just use moment? cljs-time doesn’t appear to have this out-of-the-box. thanks very much for any help.

mfikes03:01:28

@hoopes There is some support for that kind of stuff directly in Closure Library. For example,

cljs.user=> (require 'goog.date.relative)
nil
cljs.user=> (goog.date.relative/formatDay (- (js/Date.) 1e8))
"Yesterday"

hoopes03:01:53

whoa, nice. i will check that out, thanks

ag05:01:04

what do you fine scholars use instead of environ to read things off of env, when you’re in nodejs land? Seriously, I can’t find anything nice to work with js/process.env. upd. Okay I did something “plain stupid but works ™”

(require '[cljs.nodejs :as node])

(defn env->clj
  "Converts `js/process.env` into clj map"
  []
  (-> node/process
      .-env
      js/JSON.stringify
      js/JSON.parse
      (js->clj :keywordize-keys true)))
But I still need something to “inject” default values. I can of course use npm’s dotenv, but I’d rather prefer “clojuresque” approach. Maybe reading off dev.cljs.edn since I already have one

richiardiandrea15:01:41

I use dotenv because I could not find any Clojuresque way

flyboarder01:01:14

we use dotenv and have made wrappers

thheller09:01:32

why is everyone doing this JSON.stringify hack? where is this coming from?

😂 10
Karol Wójcik12:01:03

I want to thank you very much theheller for the shadow-cljs. ❤️ Dashboard and the npm integration is just perfect!! Man you did a miracle!

😎 5
Karol Wójcik12:01:49

Also documentation is looking so professional! I can see how much heart you put into this project!

thheller12:01:17

thanks very much. glad you like it. still so much left to do 🙂

joelsanchez13:01:42

it's not that uncommon in JS land to encode to json and back, to clone an object

Roman Liutikov13:01:38

really? never seen someone doing it in JS

joelsanchez14:01:27

not exactly a best practice but not that rare to see

joelsanchez14:01:25

> Good to see I'm not crazy! JSON.parse( JSON.stringify( obj ) ); seems to be a common 'shortcut'.

borkdude14:01:12

has anyone thought about porting 4clojure to self-hosted CLJS before?

ag15:01:51

> why is everyone doing this JSON.stringify hack? Yeah, I agree. That's stupid. if someone shows me an improved version of js->clj that actually works that'd be awesome

flyboarder01:01:13

when does it not work? I always use #(js->clj % :keywordize-keys true)

flyboarder01:01:39

If you want to normalize the keys (reduce-kv (fn [i k v] (assoc i (goog.string/replace k "_" "-") v)) {} (js->clj process.env :keywordize-keys true))

borkdude15:01:24

can someone summarize what’s the hack and why you should not do it, and what to do instead?

borkdude15:01:01

why would you do this hack in the first place?

dpsutton15:01:23

the hack is essentially (Long/parseLong (str 3)) but for arbitrary objects

dpsutton15:01:48

serializing and then interpreting the string representation back to data

borkdude15:01:59

so you don’t know the type of the thing, that’s why you coerce it first?

dpsutton15:01:13

(read-string (str "{:a 1 :b 2}"))

Whiskas16:01:18

Hey guys, i`m trying to use cljs.analyzer.api/ns-resolve but i’m getting a “No protocol method IDeref.-deref defined for type null”

Whiskas16:01:43

someone here knows what is the cause of this?

oconn17:01:11

@mateus.pimentel.w

(defn ns-resolve
  ([ns sym]
   (ns-resolve env/*compiler* ns sym))
  ([state ns sym]
   {:pre [(symbol? ns) (symbol? sym)]}
   (get-in @state [::ana/namespaces ns :defs sym])))
I assume state is nil. How is it being called?

rgm17:01:03

is there some good guidance for how to share a macro between clj and cljs from a cljc file? I tried #?(:clj (defmacro ... )) within the cljc (which contains a bunch of other functions), and then (ns my.ns (:require-macros [my.ns])) in a cljs file per … I think the namespaces guide… and the result was that cljs couldn’t see any of the functions in the cljc file.

rgm02:01:11

@U1UQEM078 @thheller thanks so much … I seem to have gotten it working. Plot twist, though: if I follow this method, I can do a simple (ns my.other-ns (:require [my-ns :refer [the-macro]]) if the file is CLJ or CLJS.

rgm02:01:08

if it’s CLJC, then the declaration needs to be (ns my.other-ns (:require #?(:clj [my-ns :refer [the-macro]] :cljs [my-ns :refer-macros [the-macro]]))

rgm02:01:51

I’ve added this using-a-cljc-macro-from-cljc wrinkle to the original post over at https://clojureverse.org/t/how-to-define-and-use-a-macro-in-both-clj-and-cljs/2896/7?u=rgm … does anyone know if I just hit an uncovered edge case on the namespacing/macro sugar, or is this how it’s supposed to work?

rgm03:01:41

Whoops, nope. Just operator error. Deleting.

👍 5
thheller17:01:58

@rgm in the cljc file #?(:cljs (:require-macros [my.ns :refer (a-macro-you-want-to-use)])) (not in an extra cljs file)

rgm17:01:25

I’ll give that a quick shot

rgm17:01:13

and still wrap the defmacro in #?(:clj ... ?

thheller17:01:15

oh the example misses the :cljs branch 😛

thheller17:01:48

yes, defmacro still in :clj branch

rgm17:01:07

oh, missed the refer

rgm18:01:13

whoops, gotta run into a meeting. thanks @thheller for the new idea

gdanov19:01:46

hi, I'm having troubles with :foreign-libs and :module-type :commonjs: I'm including basic file with no deps that has

module.exports.typeDefs='some string'
when compiled using deps.cljs and figwheel-main with this config
:foreign-libs [{:file        "generated/prisma-client/prisma-schema.js"
                 :provides    ["typeDefsXXX"]
                 :module-type :commonjs}
the compiled file exposes the namespace with var so it's contents end up in some local scope somehow

gdanov19:01:09

if I remove the var infront of the contents of the namespace in the compiled file everything works

gdanov19:01:32

this is the compiled code excerpt

var module$Users$gdanov$work$playground$trading_cockpit$generated$prisma_client$prisma_schema={"default":{}};
module$Users$gdanov$work$playground$trading_cockpit$generated$prisma_client$prisma_schema["default"].typeDefs=`type Account......

gdanov20:01:28

ok, got it. the var shadows the variable created by goog.provide(...) so I end up with empty namespace