Fork me on GitHub
#clojurescript
<
2019-05-31
>
stathissideris07:05:45

I’m in the middle of (re?)inventing the wheel myself

Roman Liutikov07:05:01

@vnctaing it's not really reinventing the wheel, in my experience no library for managing forms fits particular requirements, I've stopped fighting them and just doing it from scratch every time.

stathissideris07:05:38

there are some patterns that have been emerging for me, for example, I put the whole state of the for in the global db, so the path interceptor of re-frame has proven very useful

stathissideris07:05:43

⚠️ also, writing an “assoc-in”-like handler for storing state and then allowing the field to “know” where to store its value is a very bad idea

stathissideris07:05:21

I’m still trying to get the code to a boilerplate-free state, but not quite there yet

roklenarcic09:05:18

I have a cljc file with this import (:require [clojure.core.async :refer [go-loop <! promise-chan timeout]]), and it seems to work in clojurescript too. I find that weird. I thought I had to use cljs.core.async instead of clojure.core.async and that I had to specify :include-macros true.

roklenarcic09:05:45

Problem is that when I google how to write and use macros in cljc code I get tons of posts from ages ago which use old ways of cljs.

fergalbyrne10:05:30

@roklenarcic AFAIK the cljs compiler internally renames the http://clojure.xxx to http://cljc.xxx so you can use the same source for both clj and cljs.

wonko710:05:49

Hi all! is there a way to call javascript template tags in cljs ? how would

gql`query...
` translate?

mfikes10:05:27

@roklenarcic See https://clojurescript.org/guides/ns-forms and in particular these sections - clojure Namespace Aliasing - Implicit Sugar

mfikes10:05:57

This is also covered in (doc ns)

roklenarcic12:05:37

yeah I saw that. I have a cljc and clj file for same namespace. The clj file contains a macro that is used in cljc. In cljc file I have this:

(ns myproject.i18n
  #?(:cljs (:require-macros [myproject.i18n])))

; my-macro is defined in clj file
(def my-val (my-macro))
When I try to compile cljs I get this:
WARNING: Can't take value of macro myproject.i18n/my-macro at line 7 /Users/roklenarcic/clojure-projects/myproject/src/cljc/myproject/i18n.cljc

roklenarcic12:05:34

And I read that page and it says that this is valid:

(ns foo.core
  (:require-macros foo.core))

Iwo Herka13:05:55

Hello, I'm wondering what is the state-of-art ClojureScript stack? It seems that React + ClojureScript is the most popular, is that correct?

roklenarcic14:05:01

Yes, though there are numerous React wrappers

roklenarcic14:05:43

Reagent, which also has higher level Re-Frame, then Om, Om.next, Fulcro, Rum, and others

lilactown15:05:25

I want to create a seq on a JS object (it’s guaranteed immutable by convention). any prior art?

Risetto16:05:28

Hey! Does anyone have any tip on which Material UI package to use when using Reagent?

alex04:06:57

Hi Olle, i'm using Material-UI directly from NPM and haven't had any issues thus far

john16:05:25

@lilactown mmm, maybe something like

(extend-type object
  ISeqable
  (-seq [b]
    (let [gets (js-keys b)
          vs (mapv (partial aget b) gets)]
      (seq (zipmap gets vs)))))

john16:05:46

Or maybe as a js array of js arrays?

john16:05:16

How hosty do you want the sequence?

john16:05:26

You might be able to use specify if you just want to dress up a given js value

lilactown16:05:50

Well for now I punted and just converted it to a map

lilactown16:05:22

I'm trying to basically wrap a JS object to behave like a map

dnolen16:05:13

I probably would not extend-type on object

dnolen16:05:38

Just make a obj->map thing with reify - it's useful and educational to implement all the protocols

dnolen16:05:39

it's also educational to make assoc and other "update" operations work if you need it

lilactown16:05:48

Yeah, I'm going to end up implementing all the map protocols

lilactown16:05:57

Actually, so

lilactown16:05:41

The reason I'm trying to do this is because I want to give a consumer the ability to interact with the objects just like a map, but that I need to turn it back into into an object

lilactown16:05:49

I'm trying to avoid the round trip conversion

john16:05:11

cheater!

dnolen16:05:36

there's no way to avoid conversion if you implement update stuff

dnolen16:05:48

but if you make a thing that doesn't support, i.e. throws or something - it's not a lot of work

dnolen16:05:05

could also make key/entry traversal lazy w/ a JS generator fn helper

lilactown16:05:01

I've only started thinking about assoc , and that seems doable without conversion as long as I rely on only strings or keywords as keys. Where does it fall over?

dnolen16:05:27

if you need to go back to object you can't avoid conversation

dnolen16:05:39

you need to pour the extension map back in

dnolen16:05:52

dissoc also should be handled etc.

dnolen16:05:15

ready-only version is much simpler

dnolen16:05:25

update version has a lot of cases you should cover to avoid surprises

dnolen16:05:39

but also not that much more effort

lilactown16:05:01

My current strategy is to create a wrapper type that simply proxies to the JS object. Then when I need the JS object itself, I can unwrap it

dnolen16:05:19

you cannot

dnolen16:05:22

unless you intend to copy-on-write

lilactown16:05:35

That was my current thinking

mfikes16:05:54

If you make such a facility, don't call it bean

dnolen16:05:24

@lilactown there's a thing called ObjMap deprecated but it's not going to be removed that does all this stuff already

lilactown16:05:34

I only need to do all of this shallowly. So my thinking is that copy on right shouldn't be too bad

dnolen16:05:39

I think there maybe a couple of bugs since we haven't kept it up-to-date

dnolen16:05:50

specifically around MapEntry when calling seq

lilactown16:05:00

Oh sweet. I'll take a look

dnolen16:05:15

patch welcome for whatever bugs you find

borkdude16:05:50

Why does shadow-cljs introduce :default if you can already do this with :refer?

dnolen18:05:39

@ahmed1hsn can you be more specific? it's not clear what you mean

Ahmed Hassan19:05:21

@dnolen This is Hoplon lib using JQuery for de-referencing event values inside event handler functions. It implements IDeref in JQuery, I don't want to use JQuery so want to implement it in Google Closure Library. https://github.com/hoplon/demos/blob/master/inputs/src/index.cljs.hl#L38

dnolen19:05:58

saying Google Closure Library isn't adding information here

dnolen19:05:33

IDeref is a protocol you can implement w/ care on any JS type

dnolen19:05:39

nothing to do w/ jQuery or GCL

Ahmed Hassan19:05:13

ok, I'm trying to implement similar thing in GCL.

dnolen19:05:25

my suggestion would be to slow down

dnolen19:05:40

try to implement IDeref on your own type as a first step

dnolen19:05:05

there's few differences between that and extending some other type

dnolen19:05:42

(deftype Foo [a] ...)

dnolen19:05:55

vs. (extend-type YourFoo ...)

dnolen19:05:57

but I will say IMO the Hoplon thing in this case is not that meaningful

dnolen19:05:00

better to not do it at all

danielneal19:05:46

The deref here is just a bit of sugar for getting at the value of the event. It's not necessary - you can use property access.

john19:05:12

In cljs, I like to think of deref as a 'step guard' of sorts, for demarcating pure stuff from impure stuff

john19:05:29

What else would one use it for in js land? unifying interfaces across futures, promises, eventually available things?

dnolen19:05:11

you shouldn't use protocols to unify stuff outside of your codebase

dnolen19:05:31

extending types you don't control and then publishing it is a face palm

john19:05:57

I thought he was talking about doing a derefable thing in js

dnolen19:05:40

right I'm just saying stating a general related point because you can't achieve unification in a meaningful way

dnolen19:05:45

leave the JS junk alone is what I say

john19:05:21

ah right