Fork me on GitHub

I'm importing codemirror using cljsjs, in project.clj: [cljsjs/codemirror "5.44.0-1"] But getting error compiling with shadow-cljs The required namespace "cljsjs.codemirror.mode.clojure" is not available, it was required by "my_app/views.cljs" . Any ideas?


shadow-cljs does not support cljsjs packages. you just use the npm packages directly instead. ie npm install codemirror

👍 1

Wow, thank you


And does figwheel support this syntax?


I tried but get error Error: Cannot find module '@cljs-oss/module-deps'


I have a library that using codemirror with figwheel and main project with shadow-cljs, seems they use different approach to require


in that case to make it easier to bridge you can create a helper cljsjs namespace


with just

(ns cljsjs.codemirror.mode.clojure
  (:require ["codemirror/mode/clojure/clojure"]))


that'll let figwheel use the cljsjs package and instruct shadow-cljs to map the clojure mode to the npm package


you can make figwheel work without the cljsjs package as well


but I don't know how you configure that


it is supported though


Well, figwheel prints:

----  Could not Analyze  src/cljsjs/codemirror/mode/clojure.cljs  ----

  No such namespace: codemirror/mode/clojure/clojure, could not locate codemirror_SLASH_mode_SLASH_clojure_SLASH_clojure.cljs, codemirror_SLASH_mode_SLASH_clojure_SLASH_clojure.cljc, or JavaScript source providing "codemirror/mode/clojure/clojure" (Please check that namespaces with dashes use underscores in the ClojureScript file name) 


Add helper cljsjs namespaces to main project and it finally works)

Jérémie Salvucci13:05:03

Hi, I'm using the component pattern with re-frame ( I'm trying to interact with a canvas element so this pattern fits my need perfectly. Nevertheless, I have a question related to "concurrency", when the component-did-update lifecycle function is called, is it a good practice to call re-frame/dispatch to actually trigger events in the re-frame application (re-frame -> reagent through subscriptions and reagent -> re-frame through 'dispatch events')? Because right now, my application freezes sometimes and I'm wondering if this practice may actually be the cause.


There's #re-frame that's better suited for this question. But no, freezing shouldn't be caused by that. It's more likely that you have a CPU hog somewhere. You can use your browser's profiling tools to figure out what's going on. But also, you shouldn't be using dispatch in a component at all, except for user-triggered events:

Jérémie Salvucci14:05:21

thank you, I wasn't aware of #re-frame, I'm going to find a way to avoid the dispatch then. I was asking because the issue happens only on mobile phone using Metamask browser (difficult to track what's going on).


What course/source you used to learn web fundamentals such MVP, http,… when you were beginning? Which source would you highly recommend? I noticed as a beginner that it is as if teaching material are teaching, for example MVP based framework to beginners but the foundational understanding of web ideas (MVP itself) is assumed without merit.


> MVP I quickly gave up following those trends - pretty sure new abbreviations were appearing faster than I could find what they truly meant. :D Even nowadays, I'm not sure whether delving into the strictness of it all is worth it when every framework ends up being leaky and with a bunch of "well, actually" or "for practical reasons" in its documentation.

👍 1
😆 1

Not sure how useful my answer would be, but I used to follow tutorials to the best of my abilities and then tried delving deeper into each aspect of the resulting code: • Here we set up a DB connection - how exactly do we set it up? What is a DB connection anyway? • Here we serve static files - how does it know what to serve? What does "serve" mean in the first place? How does a client request such a resource? • Here we have frontend code - how does it start? Where does it reside and how does it get there? What makes it tick? And so on and so forth, for every thing I would find somewhat interesting and not entirely obvious.


When I started out with web dev 10y ago I made the same mistake as many others. I focused on code organisation, paradigms, patterns, frameworks etc. instead of actual web fundamentals. It was also a time where a shift happened in how to construct frontends and it was all really messy. Instead I suggest you focus on actual fundamentals. First and foremost that means protocols. Know what they guarantee, what they assume. Know how to interact with them and how to play nice with them. Just TCP/IP and HTTP are vast on their own. Secondly the platform. If you deliver something to the browser, you want to know what that means, how it operates, what the most useful features are. Again, it's vast. Then there is your storage. You get more flexibility and choices there. Having at least solid, basic knowledge of SQL will get you very far and you can avoid the terrible complexities of ORMs. Then you want to start learning to construct a backend that makes little assumptions about the outside. I have the mindset of "the frontend assumes the user is a friend, the backend assumes the user is an enemy". Start learning about authentication, authorization, data validation/parsing, preserving state/knowledge via sessions, tokens and that kind of thing. All of the MVC/MVP/MVVMSMWMS whatever things kind of fall out of the fundamentals. It's different layers that require different modes of thinking and you coordinate between them with data and code.