This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # babashka (7)
- # beginners (25)
- # calva (22)
- # cljs-dev (1)
- # clojure (62)
- # clojure-europe (118)
- # clojure-hamburg (4)
- # clojure-israel (2)
- # clojure-nl (2)
- # clojure-uk (6)
- # clojured (1)
- # clojurescript (23)
- # conjure (11)
- # cursive (3)
- # datomic (14)
- # duct (2)
- # emacs (12)
- # figwheel-main (1)
- # gratitude (1)
- # hyperfiddle (4)
- # joyride (72)
- # lsp (46)
- # luminus (1)
- # malli (1)
- # off-topic (54)
- # pathom (19)
- # polylith (11)
- # releases (2)
- # sci (22)
- # shadow-cljs (4)
- # vim (11)
- # xtdb (52)
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
this would be an example of how you require it then https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/cljs/ui/components/code_editor.cljs#L3-L5
I have a library that using codemirror with figwheel and main project with shadow-cljs, seems they use different approach to require
(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
for codemirror that already exists, just not for the clojure mode https://github.com/thheller/shadow-cljsjs/blob/master/src/main/cljsjs/codemirror.cljs
Well, figwheel prints:
Hi, I'm using the component pattern with re-frame (https://github.com/day8/re-frame/blob/master/docs/Using-Stateful-JS-Components.md). 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: https://day8.github.io/re-frame/FAQs/LoadOnMount/
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.
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.