Fork me on GitHub

Hrm though should probably check how Clojure deftypes work with this - if they do should think about it

Alex Miller (Clojure team)01:02:15

Dashes are not allowed in Java field names

Alex Miller (Clojure team)01:02:48

If that is the question


How to debug clojurescript with target nodejs? i don't want many things mostly to know the line of error in cljs file (not the .js file), i use shadow-cljs


i saw online on stackoverflow, that i could use source-maps if target if the browser, for nodejs is something we can do? If there is a link or tutorial it will help alot, thank you


source maps work the same in node. just :compiler-options {:source-map true} if you want source maps for a release build


for development that is automatically included


for node you can include it when running node


node -r source-map-support/register compiled.js


thank you alot : ) i will try it


is there an effective way to develop macros using the node REPL?


I tried defining it in a .clj w/ the same namespace and requiring it in my cljs ns. when I invoke it I get

WARNING: Can't take value of macro


ah it's only when I use it in the same cljs ns


Just curious what approach do others take with the inital load of there apps, currently I have a loading page with a spinner, while the app launches do people generally style index.html the same as the site and have it replace the content or are there other tricks to speed up the initial launch ?


I do exactly that - a spinner with all its trivial styling embedded right there in index.html, and then replace with with Reagent's render.


Some people do SSR. I don't use it because SEO is not that important for my projects right now, and it's a hassle to set up.


yeah, I kind of don't like that when you goto the site you get a spinner for a few seconds, thought this might just be a case of duplicate the style in index.html or have no style and leave the page white until the app loads in


I guess the other way would be to have the layout defined in index.html with multiple react entry points into the document, to bring in the nav and body later


Or it can be a single React root that just replaces the baked-in markup with an identical one. Also, just in case - consider figuring out what exactly takes that much time. There are usually improvements one can make here: • Use a much faster server for static resources, if the one you're using is slow • Use compression of static resources • Use module splitting • Get rid of huge dependencies (my pet peeve here is Specter) • If you embed large data files with macros during compilation - don't, instead switch to AJAX


Generally the solution(s) are spinner or skeleton, but, as p-himik noted, you can usually get the initial load down to sub 2 seconds, so my approach is add in one of the two options above and then try to get the load time downs so the above aren’t really needed.


code splitting is not something I have looked into in clojurescript so could be another option, I think the spinner option I find a bit jaring but I guess if I had a skeleton in place that would mitigate that issue


anyone aware of any info on code splitting in particular when working with a figwheel project, blogs or anything like that to get a feel for it ?


Shadow-cljs has good documentation on the topic, but I'm not sure whether it can be applied to Figwheel...


I have a foreign lib that is a React UI component library and it uses Webpack to build a chunked version for code splitting purposes. The entry file is referenced in the Figwheel build file project.cljs.edn I would like to know how I get the numerous chunks to copy to the root output asset path so that the chunks are available when the website serves? As a last resort I will configure my site to use it as an npm package instead. The reason why I am not doing so now is that I would prefer to introduce as little change as possible to the project right now. If npm is the only way to go or is a best practice, then I will do that instead.


@cbillowes hrm, just manually copying the chunks over doesn't work? though I guess Webpack has a loader of some kind?


Thank you for your input yesterday. I managed to find the correct assets directory to copy the chunks to. 🙈 I appreciate your help 🙂


@dnolen I am in the process of figuring out where to copy the chunks to as I know it should be in the root of the asset-path. I will get more context of the structure of the project tomorrow (UTC +4). I’m not sure about the Webpack loader though. Assuming I understand you correctly, the way I understand it is that the entry js file knows which components exist and what to load when referenced.


So I’m noticing record instances can’t be destructured like maps. e.g.

(let [{:keys [foo]} (MyRecord.)]
         foo) ;; nil 
My intention was to use a protocol+record to declare an interface for a React hook used across mobile and web. but since React hooks often return maps (which can be destructured), this behavior could lead to subtle surprises, so wondering if there are recommendations or workarounds edit: the issue was that record functions are called directly via their protocol. thanks @ for clarifying this


Huh? Is this not the behavior that you see?

=> (defrecord R [a b c])
=> (def r (R. 1 2 3))
=> (let [{:keys [a b c]} r] [a b c])
[1 2 3]


Note that JS objects are not CLJS maps, so you can't destructure JS objects that way.


oh wow, you’re example works. which is good news but looks like there’s something wrong in my code 😪


you’re accessing the initial values passed to record, not it’s functions


Its functions never become fields on the object. Why would you even need functions when it comes to destructuring? You just require the ns with the protocol and use those functions directly.


i’m creating a react hook, and returning an object or map with values+functions that way is a common pattern


(ns a)

(defprotocol P
  (foo [_]))
(ns b
  (:require b))

(defrecord R []
  (foo [_] "..."))

(b/foo (R.))  ;; <- this is how you use `foo`.


> You just require the ns with the protocol and use those functions directly. hm, maybe i’m using protocols wrong though


That's a common pattern in JS though. :)

👍 1

honestly, my instincts too were that i was using them wrong but none of the resources online that talk about records explain what you just mentioned


(that i read, at least)


anyway, thanks for this clarification

👍 1

do you use a special name to differentiate records? e.g. use-record instead of use-context


I don't use React hooks if that's what you mean. But overall, IMO the naming should not depend on the type. context above is not the type, really - it's a semantic description.


my thinking was that adding the type to the name could indicate proper use and avoid confusion but this may be specific to my use-case, since react hooks already have a certain pattern of usage


Yeah, I don't know, but I don't think I'd do it. After all, we create view functions that are very specific. And yet, we don't name them page-view, table-view, footer-view, and so on. It might depend on the context, of course - I'm just talking about the general case.

👍 1