Fork me on GitHub
#om
<
2016-11-05
>
levitanong07:11:54

has anyone tried using om as a checkout dependency?

anmonteiro09:11:32

@levitanong the path to the externs needs to be a file system path

anmonteiro09:11:51

not a "classpath path"

levitanong09:11:03

@anmonteiro oh, so if I have “svg.ext.js”, it has to be at the root of the project?

anmonteiro09:11:05

e.g. if they're in resources/public/ext.js you need to pass that

levitanong10:11:15

Thanks, @anmonteiro! Will try it out now.

levitanong10:11:54

@anmonteiro hmm… Problem still persists. 😕

anmonteiro10:11:22

@levitanong can you send me a snippet of the om.dom code that fails for you?

levitanong10:11:31

the extern file now shows up in the target, but that’s about it

anmonteiro10:11:24

@levitanong OK found the problem

anmonteiro10:11:37

this is a problem with the React externs in CLJSJS

anmonteiro10:11:05

@levitanong for now you can get around it by adding just this to an externs file:

React.DOM.clipPath = function(props, children){};

levitanong10:11:03

trying it out

levitanong10:11:39

Thanks so much!

levitanong10:11:58

@anmonteiro I suppose the issue extends to the other tags that Alvin found, and to fix the extern for those, one would just add an entry for each one?

anmonteiro10:11:26

those are missing too it seems

anmonteiro10:11:32

I'm sending a PR to CLJSJS to fix it

anmonteiro10:11:59

@levitanong although var is there

levitanong10:11:03

@anmonteiro: hmm. I wonder why Alvin found a problem with var.

anmonteiro10:11:11

probably an oversight

anmonteiro10:11:15

PR in place, I'm going to close the Om issue

levitanong10:11:42

@anmonteiro: alrighty! Once again, thanks!

tobiash18:11:51

@anmonteiro would it be feasible for compassus to have multiple "active" routes at the same time and use a composite query of all active routes?

tobiash18:11:47

in order to support "hierarchical" routes - like they are in rn navigator

tobiash18:11:36

because rn actually keeps the the higher level route components (aka "scenes") mounted. I'm currently setting the top navigator route as active compassus route, so the other active scenes dont get query updates

anmonteiro19:11:40

@tobiash that sounds like an interesting problem

anmonteiro19:11:19

I don't think we can support multiple active routes, but we could probably support Compassus-managed nested union queries somehow

tobiash19:11:57

that would be very useful for this scenario. though normally it does not matter to much when the active parent scenes do not query, since its out of sight anyway, but it might when a scene has to trigger some kind of external side-effect based on the query

tobiash19:11:14

though it can be argued that such side-effects should not belong in a component/scene

tobiash19:11:15

but lots of React Native components unfortunately require stuff like that

tobiash19:11:42

but I imagine in a typical web application hierarchical routes are much more common and then the upper-level route components would be visible and require queries

snoonan19:11:39

@anmonteiro: While adding to the PR for react.ext.js, add the 'use' 'image' and 'textpath' as well.

anmonteiro19:11:21

@snoonan I'll add image, but the others are not in React.DOM

snoonan19:11:39

I was adding '''(def dom-use (js/React.createFactory "use")) (def dom-image (js/React.createFactory "image")) (def dom-textpath (js/React.createFactory "textpath"))'''

anmonteiro19:11:59

you still need to do it for use and textpath

snoonan19:11:01

(I'll figure out how to paste code one day)

anmonteiro19:11:10

use 3 backticks 🙂

snoonan19:11:33

tick/backtick.. The same really.. 🙂

snoonan19:11:00

Ya, just so easy to mis-read on screen in some fonts

sophiago20:11:17

hi. i'm trying to do some research today on which clojurescript react wrapper would be right for me (after trying to jump right in and discovering reagent was likely the wrong one). my background is having worked a bunch with react in js, but with with top-level api not jsx and at least initially wanting something true to form with that. to be clear, i don't want to use js interop and i would like to replace my container component with a global atom, but otherwise i'd like porting UI components to be as straightforward as possible. one thing is that i've been using react.createFactory a lot lately. i'm not sure any of my options wrap that (possibly quiescent?), but i also understand it's syntactic sugar i should be able to work around anyway. so seems i'm largely choosing between om and quiescent, the former offering me much more support at the expense of flexibility. and then i'm still not sure how rum plays into all of this. any advice? i can provide short samples of the type of js components i tend to write if anyone cares to look that much too. thanks

anmonteiro22:11:06

@sophiago Om - Next, which is the one actively being developed - is flexible in that you can develop almost like you'd do in plain React, with the possibility of adding UI queries later (a la Relay/GraphQL and Falcor)

anmonteiro22:11:55

it excels if you want a fullstack story but it's not something that is required

anmonteiro22:11:12

if you always used React without JSX, you'll probably find the om.dom API very familiar. And creating factories of your components is actually required

anmonteiro22:11:28

here's a simple example to get you started:

(ns my.ns
  (:require [om.next :as om :refer [defui]]
                 [om.dom :as dom]))

(defui MyComponent
  Object
  (render [this]
    (dom/div nil
      (dom/h1 nil "Page Title")
      (dom/div nil
        (dom/p nil "Some text")))))

(def my-component (om/factory MyComponent))

;; in other components, you call `my-component` as it were any React element, e.g.:
;; (my-component #js {:a-prop :foo} child1 child2)

sophiago22:11:22

@anmonteiro thanks for reading all that! looking through this now, but glad to hear all these things given the rationale around om seemed to match my personal cljs libraries (despite being unsure about these issues) and it having the most support is definitely nice since this is hopefully going to be a major work thing for me...at least if i can pitch it well

anmonteiro22:11:35

@sophiago one more thing I forgot to mention. Om is actually opinionated in that it requires you to have a single source of truth, i.e. your app state in a single atom. that seems to match your needs

sophiago22:11:37

yup. that would make absolute sense to me

sophiago22:11:53

and as far as the backend stuff: not like this is my only project with it, but in this case there's no chance of using clojure for that as it's a large preexisting codebase that's very low-level (finance stuff)

anmonteiro22:11:02

@sophiago you can still have some benefits of i.e. data-driven queries in the frontend but still communicate with a REST client

anmonteiro22:11:54

or even forego these queries entirely and load data into your app in other ways

sophiago22:11:37

ok, so i would imagine this would get me quickly up to speed to port over a small component to wrap my head around it? https://github.com/omcljs/om/wiki/Quick-Start-(om.next)

anmonteiro22:11:14

I suppose so, Tony Kay's tutorial is also a good resource: https://github.com/awkay/om-tutorial

sophiago22:11:08

ha. you sounded really lukewarm. i'll go with the latter then

anmonteiro22:11:03

wasn't my intention, probably just a consequence of Internet chat 🙂

anmonteiro22:11:21

you should definitely go through the tutorials in the Wiki

sophiago22:11:21

true. so further reading maybe?

anmonteiro22:11:36

maybe both at the same time

anmonteiro22:11:03

the wiki ones are "official" and written by David, if that matters to you

sophiago22:11:43

well, currently i'd like to crank out something rather quickly tbh so i can benchmark it vs. approaches i don't like given the client factor

sophiago22:11:53

but i'll figure that out so no worries

anmonteiro22:11:09

happy to help along the way

sophiago22:11:58

and then wondering...i most recently have been using factories to reflectively spawn UI elements. so if you can bear a really bizarre example: the output of one slider controls how many sliders are generated. that's the type of thing you think it would be equally obvious how to do with an atom vs. container component (obviously that approach is otherwise refreshing, but i could see this being potentially tricky)?

sophiago22:11:28

if you can stand the mixed up html/js/some css it's a very short repo

sophiago22:11:32

i'm just not sure how much that verbal explanation translates and then obviously there's the element of i would surely do it differently in cljs than js too

anmonteiro22:11:37

yeah you could do the same in Om

anmonteiro22:11:15

(defui X
  Object
  (render [this]
    (dom/div nil
      (map some-factory (:some-list (om/props this))))))

anmonteiro22:11:56

btw there are some simple devcards examples in the Om repo if you wanna look at some code https://github.com/omcljs/om/tree/master/src/devcards/om/devcards

sophiago22:11:57

right, that's what i meant...much cleaner. didn't think sooo clean you'd just whip up an example tho 🙂

sophiago22:11:36

you're saying some of those examples are similar to implementing the snippet you just shared?

anmonteiro22:11:23

for the most part, not really

anmonteiro22:11:45

I mean, the render code sure is, but it also has the query stuff

anmonteiro22:11:58

which I haven't understood if you are going to need or not

sophiago22:11:56

i'm not sure yet either

sophiago22:11:50

i usually use json with fetch...but doubtful for this

sophiago23:11:36

it's an in-house thing

anmonteiro23:11:45

I mostly just use goog.net.XhrIo

anmonteiro23:11:23

almost every ClojureScript AJAX library is a simple wrapper around it anyway

sophiago23:11:39

yeah see i think that wouldn't make sense here

sophiago23:11:50

i have essentially one user

anmonteiro23:11:11

that + core.async normally does the job. but if you're new to Clojure(Script) probably not good to start with core.async right away

sophiago23:11:13

but any speed matters

sophiago23:11:42

no, that's something i would add in for the callbacks in the demo to benchmark for this probably

sophiago23:11:59

or rather in place of the callbacks

sophiago23:11:03

oh that's cool

sophiago23:11:48

tbh good to have that as boilerplate because i'm not super great with core.async, but i can use it for a mouse event

anmonteiro23:11:31

you don't need any core.async though. a goog.net.XhrIo call with a callback seems perfectly fine to start with

sophiago23:11:06

i guess it's just i never jumped into closure library despite knowing why i should. i'll keep this in mind though

anmonteiro23:11:04

well if you don't have browser requirements you can even do your normal fetch

sophiago23:11:31

right. no browser requirements. just speed. but that's a bit down the line

sophiago23:11:09

i'm more thinking now about how to handle the charting, which is why i'm happy to have likely landed on om out of all the choices of react wrappers

sophiago23:11:30

seems to give me the best choices if i'm looking at libraries for that

sophiago23:11:23

although i'm also wondering about just using UI components with a factory pattern and core.matrix

sophiago23:11:54

like what i could possibly put together as far as charting out of that

sophiago23:11:16

(i was contacted based on graphics experience, not graphic design experience)

anmonteiro23:11:29

you can probably just use the charting library of your choice with Om

anmonteiro23:11:00

if it works in React, it should work in Om

sophiago23:11:39

i do wonder about the state of that d4? d3 except with react at the core?

sophiago23:11:56

it didn't seem quite stable when i looked recently

anmonteiro23:11:31

I've never done any charts on the web, so I wouldn't know

anmonteiro23:11:36

the little I tried was using http://recharts.org/

sophiago23:11:05

i'm trying to think of what cljs react stuff i saw two different charting libraries. i think it was in reagent

sophiago23:11:22

btw, it's so funny having my expectations flipped of om vs. reagent as to which would more closely track react