When developing a library what's the standard way for implementing asynchronous code? Such as callback, promise, core.async.

With callback, the developer could implement promise or core.async if they wanted to

However I believe promise would be convenient to have.

I find in general core.async has too much overhead compared to callback and promise and I usually defer using it unless I have a problem that core.async is good at solving

So I'm thinking of overloading my async functions so that they can take a callback, but will return a promise if the callback is not provided. What are other peoples thoughts?

i'd say don't force async stuff on your users, callback is fine, let them do it their way

also if possible at all, hide asynchronicity

there was a nice talk about it

@carkh I plan on wrapping a library so the async methods would need to be exposed to support asynchronous

When you say hide asynchronocity, what do you mean by that?

i'm trying to find that talk but i can't ...

they were providing examples like om/fulcro

there is much asynchronicity in there, but you don't see it as a library user

oh okay I see what you mean

or pedestal interceptors, as a user you don't care or even need to know if it's using core.async

and indeed it's only using it when necessary

(if i recall correctly)

ah there it is https://www.youtube.com/watch?v=096pIlA3GDo&list=PLy9I_IfUBzKJj2mPG4k_1DZgZr2b0D3bh&index=4&t=0s

oh nice, thanks!

that's weird - I can't believe there is no way to find requires of a namespace in repl, yet find usages of variable. Am I just missing something?

Hi All, I couldn't find a page on http://clojurescript.org which introduces javascript interop and the #js literal. Is there an authoritative reference?

There’s a good summary at https://cljs.info/cheatsheet/

does anyone know of any libraries for generic plugin type behavior? Like if i wanted to write a cljs ui with features enabled / disabled by serverside config, and have a clean api for registering new features into the app without interfering with existing features, attach metadata about how they could expose metrics or potentially communicate with each other, hints about layout, etc. I'm not looking for something that actually does metrics or layout, just looking for a solid, extensible foundation for implementing highly modular behavior on top of. Maybe that's just super idealistic though

@chrisjswanson, idealism, yes. I love it! If there is no such a library. We have to act and getting together to create one.

@scknkkrer maybe that library is named Clojure 😛 but seriously it seems like a common enough pattern, i'd expect it's been done in other languages and frameworks to various levels. Ironically, the most modular pluggable ui component and behavior type framework i can think of is Drupal. I'm not a big fan of php and don't know that it'd be wise to draw inspiration from their implementation, but no doubt they've thought about the problem to great length. A light weight clojure library with cms-like isolation of ui components and any functionality they add to the system would be a fun project

I'm particularly interested in it for mobile apps, to turbocharge a remote config solution

:advanced compilation makes building "highly modular" things kind of tough if not impossible so you'd have to make a lot of compromises if you want to build something that is truly modular

hmmm, that is something i hadn't considered much

tbh i don't know half as much about advanced compilation as I should; sounds like now's the time to learn a bit more

thanks for the tip

as long as you have a single "project" that contains all of the modules, you can use code splitting to modularize your code base pretty efficiently

the issue is when you want to allow external parties provide plugins or modules

Going through some re-frame tutorials. I saw some folks using (rf/path) in their event handlers that confused me. They had written something simple like:

(rf/reg-event-db
  :form/set-field
  [(rf/path :form/fields)]
  (fn [fields [_ id value]]
    (assoc fields id value)))

(rf/reg-event-db
 :form/set-field
 (fn [db [_ id value]]
   (assoc-in db [:form/fields id] value)))

Wondering what best practice, or most normal is?

Or if they truely are equivalent.

@david.folkner By looking at the source code, they are not equivalent .. They simply yield the same output

As you are adding an interceptor to the chain, there's a bit of more logic involved (which I assume is negligible)