This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-11-05
Channels
- # aleph (2)
- # beginners (93)
- # boot (9)
- # cider (1)
- # cljs-dev (50)
- # cljsrn (4)
- # clojure (32)
- # clojure-russia (58)
- # clojure-spec (23)
- # clojurescript (146)
- # clojurewerkz (2)
- # component (1)
- # cursive (2)
- # hoplon (163)
- # off-topic (4)
- # om (117)
- # onyx (8)
- # pedestal (1)
- # re-frame (13)
- # reagent (34)
- # spacemacs (17)
- # test-check (1)
- # untangled (3)
has anyone tried using om as a checkout dependency?
@levitanong the path to the externs needs to be a file system path
not a "classpath path"
@anmonteiro oh, so if I have “svg.ext.js”, it has to be at the root of the project?
e.g. if they're in resources/public/ext.js
you need to pass that
Thanks, @anmonteiro! Will try it out now.
@anmonteiro hmm… Problem still persists. 😕
@levitanong can you send me a snippet of the om.dom
code that fails for you?
the extern file now shows up in the target, but that’s about it
@levitanong OK found the problem
this is a problem with the React externs in CLJSJS
https://github.com/cljsjs/packages/blob/master/react/resources/cljsjs/react/common/react.ext.js
@levitanong for now you can get around it by adding just this to an externs file:
React.DOM.clipPath = function(props, children){};
trying it out
@anmonteiro it works!!!
Thanks so much!
@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?
those are missing too it seems
I'm sending a PR to CLJSJS to fix it
@levitanong although var
is there
@anmonteiro: hmm. I wonder why Alvin found a problem with var
.
probably an oversight
PR in place, I'm going to close the Om issue
@anmonteiro: alrighty! Once again, thanks!
@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?
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
@tobiash that sounds like an interesting problem
I don't think we can support multiple active routes, but we could probably support Compassus-managed nested union queries somehow
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
though it can be argued that such side-effects should not belong in a component/scene
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
@anmonteiro: While adding to the PR for react.ext.js, add the 'use' 'image' and 'textpath' as well.
@snoonan I'll add image
, but the others are not in React.DOM
https://github.com/cljsjs/packages/pull/814/commits/670a2981874aa5f11f102305f411b1ba85a19fb8
done ^
I was adding '''(def dom-use (js/React.createFactory "use")) (def dom-image (js/React.createFactory "image")) (def dom-textpath (js/React.createFactory "textpath"))'''
you still need to do it for use
and textpath
use 3 backticks 🙂
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
@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)
it excels if you want a fullstack story but it's not something that is required
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
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)
@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
@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
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)
@sophiago you can still have some benefits of i.e. data-driven queries in the frontend but still communicate with a REST client
or even forego these queries entirely and load data into your app in other ways
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)
I suppose so, Tony Kay's tutorial is also a good resource: https://github.com/awkay/om-tutorial
wasn't my intention, probably just a consequence of Internet chat 🙂
you should definitely go through the tutorials in the Wiki
maybe both at the same time
the wiki ones are "official" and written by David, if that matters to you
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
happy to help along the way
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)?
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
it's this like weird demo here: https://github.com/Sophia-Gold/dancing-sliders
yeah you could do the same in Om
(defui X
Object
(render [this]
(dom/div nil
(map some-factory (:some-list (om/props this))))))
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
right, that's what i meant...much cleaner. didn't think sooo clean you'd just whip up an example tho 🙂
you're saying some of those examples are similar to implementing the snippet you just shared?
for the most part, not really
I mean, the render code sure is, but it also has the query stuff
which I haven't understood if you are going to need or not
I mostly just use goog.net.XhrIo
almost every ClojureScript AJAX library is a simple wrapper around it anyway
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
no, that's something i would add in for the callbacks in the demo to benchmark for this probably
right. this is a somewhat idiomatic example of doing remote stuff https://github.com/omcljs/om/blob/master/src/devcards/om/devcards/autocomplete.cljs
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
you don't need any core.async
though. a goog.net.XhrIo
call with a callback seems perfectly fine to start with
i guess it's just i never jumped into closure library despite knowing why i should. i'll keep this in mind though
well if you don't have browser requirements you can even do your normal fetch
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
although i'm also wondering about just using UI components with a factory pattern and core.matrix
you can probably just use the charting library of your choice with Om
if it works in React, it should work in Om
I've never done any charts on the web, so I wouldn't know
the little I tried was using http://recharts.org/