Fork me on GitHub
#clojurescript
<
2022-10-05
>
opqdonut05:10:10

What's the nicest way to use webfonts with shadow-cljs? In the JS world it seems people just do something like import "foo/font.css" and the actual font files get bundled into their app.js? I haven't found a way to do that with (shadow-)cljs. Is the only solution the oldschool way of serving the font files from my backend? That means I need my backend build to fetch some npm deps, since npm fontsource seems to be the easiest way to get various fonts.

p-himik07:10:29

> the actual font files get bundled into their app.js? Not really - you gotta use webpack or maybe something similar and then it just creates code that loads imported static resources from the server. IMO the oldschool way is the best one, unless you have optional modules that have their own static resources. In which case you can use something like what's described here: https://stackoverflow.com/a/4900495/564509

agh2o11:10:14

#re-frame question: Trying to create a reusable re-frame component. This component is supposed to be an editor. It has its own events and is supplied with a db-path (by the user) where it keeps the editor's state. The state it keeps is not supposed to be touched by the user. in turn the user needs to supply functions for different events. One such event is the update-doc. My question is whats the best way to call this event.. Options I've considered • The user supplies a function to be called with the new doc value. The editor's on-change calls it via a specialized effect (that calls the function). (the user will probably supply a function that calls re-frame's dispatch on his event) • The user supplies a namespaced keyword of the event. The editor's on-change calls it via a dispatch effect. (This somehow seems a bad practice but I can't say exactly why). Are there any options I've missed? Thanks in advanced

p-himik11:10:24

Why didn't you ask it in #re-frame though? :) Slack even highlighted that "hashtag" as a channel. In any case, for truly reusable components it's better to write them in plain Reagent, without any reliance on re-frame.

p-himik11:10:45

Part of the reason for why e.g. re-com is independent from re-frame.

agh2o11:10:31

Wasn't aware there was a re-frame channel. Should I re-post it there?

p-himik11:10:55

Nah, that's fine - we're already discussing it here. As long as it stays in a thread.

agh2o11:10:29

About making a purely reagent component. I feel that this editor component that is set out to be feature-rich/complex would loose the whole re-frame benefits. I like the re-frame idea of a single state

p-himik12:10:20

You can impose those benefits from the outside. E.g. you have an <input> field, and by itself it doesn't know about re-frame, it stores its state internally. But if you provide :on-change #(dispatch [:change-input-value %]), along with a corresponding :value, it will store its state in the app-db. Same deal here.