This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-11-08
Channels
- # aws (3)
- # bangalore-clj (1)
- # beginners (47)
- # boot (137)
- # cider (1)
- # cljs-dev (67)
- # cljsrn (7)
- # clojure (122)
- # clojure-argentina (5)
- # clojure-berlin (4)
- # clojure-czech (12)
- # clojure-france (27)
- # clojure-italy (9)
- # clojure-russia (88)
- # clojure-spec (44)
- # clojure-uk (157)
- # clojurebridge (2)
- # clojurescript (236)
- # datomic (5)
- # devcards (3)
- # dirac (23)
- # emacs (13)
- # hoplon (29)
- # incanter (1)
- # leiningen (41)
- # microservices (1)
- # off-topic (78)
- # om (145)
- # onyx (13)
- # parinfer (8)
- # pedestal (4)
- # planck (15)
- # protorepl (1)
- # re-frame (72)
- # reagent (25)
- # ring (2)
- # specter (23)
- # test-check (9)
- # untangled (106)
- # vim (8)
- # yada (1)
@levitanong almost certain i would actually bypass all the svg parts for this and go straight canvas. tho still makes sense to use a library rather than thinking i could do charting by hand if that's what you mean. having looked into recharts, it seems ideal
anyway, i went through the om-next tutorial yesterday and really love it. not only does it seem to fit the way i use react perfectly, but the backend integration should end up being amazing when it reaches that
i am wondering if there's a way to add inline styles to defui? i don't see it in the documentation, but would imagine so
@sophiago: this is some work done on mixing styles with om: https://github.com/untangled-web/om-css. I haven't looked at it myself, just know of it.
That’s awesome. No more massive styling lines like in regular React components.
Haha:)
at first i thought it was a general full stack clojure thing then realized i probably wouldn't be using their modules
Here are the regular Facebook docs for React component styling: https://facebook.github.io/react-native/docs/style.html
that's a huge deal for me...it's what allows you to map a factory pattern to locations in the viewport
Oops I thought that was React. Same concept though.
Unless you just use regular CSS.
Yeah totally.
I think the components are the same though. I’ve definitely seen styling in Om stuff somewhere. Or maybe it was Reagent.
since in om-next everything has to be a factory then how is it imagined you position them without some amount of inline styles?
Sorry I’m not being very helpful 😛
i would imagine you can just do this with om-next and it hasn't been documented yet because it's in alpha
I literally think it’s just something like this:
(defui AppRoot
static om/IQuery
(query [this]
'[:app/msg])
Object
(render [this]
(let [{:keys [app/msg]} (om/props this)]
(view {:style {:flexDirection "column" :margin 40 :alignItems "center"}}
(text {:style {:fontSize 30 :fontWeight "100" :marginBottom 20 :textAlign "center"}} msg)
(image {:source logo-img
:style {:width 80 :height 80 :marginBottom 30}})
(touchable-highlight {:style {:backgroundColor "#999" :padding 10 :borderRadius 5}
:onPress #(alert "HELLO!")}
(text {:style {:color "white" :textAlign "center" :fontWeight "bold"}} "press me"))))))
I know that’s for React Native via Re-Natal (#cljsrn), but I’m almost positive the Om.Next components are the same for web because both React and React Native use JSX and its built-in styling I believe.
But I’m probably crazy. I’d just say play with it until the documentation comes out like you said.
Hope it works.
that works for you? i was thinking something like that, but ending up needlessly tinkering with my config instead for a while
@keatondunsford i'm getting a bunch of errors on my first pass through this. not sure how much is really specific to om-next?
Let me try messing with the source in the Om Tutorial and see if anything works.
I might be totally wrong but just trying to help.
i'm not getting any errors...it's just not rendering. pretty usual story for first pass through a framework after the tutorial 😛
Yeah totally. The code I shared has React-Native specific UI variables like View and Touchable-Highlight. I was only pointing it out for the syntax as it related to how the maps worked and stuff.
Basically what I was getting at was if you looked at the React docs for the right vars to style your JSX (or Om equivalent), and then just copied the order of things, it might work. But idk
mainly the reconciler and using add-root! for that as well as js to render instead of using another defui. i've been shown the latter both ways
@anmonteiro was very helpful pointing me in the right direction with factories so perhaps i'll catch him when timezones line up
Yeah he’s the man
What project are you working on? Curious:)
right now just porting some components from js. eventually realtime financial charting, although i think the client i'm contracting for is delaying it 😕
it's too bad because i know i'll kill it on benchmarks, we have prior work history together that can't be beat, and my hope is this will lead to a permanent job, but seems that's really entirely dependent on his success more than my ability...and i'm just not used to being in that position
although i also think he imagines paying me much more than i'd accept if we were negotiating so it's kind of hilarious in that sense
That’s awesome!! I hope you get it. All this Om mastery will just up your chances like crazy if you can wow him with Lispiness.
it's really not that... i wanted to close the deal based on benchmarking it being magnitudes faster than his previous code, but very clearly he's already sold on me and just doesn't need the frontend immediately and also wouldn't pay someone less than what he deemed standard. where we used to work payed developers a shitload (i wasn't a developer there...) and is basically in a startup phase although not in an industry that depends on investor capital. so it's a timeframe thing mainly and further off than i was hoping
i just ported peter henderson's picture language to clojure for canvas interop, which was rather difficult due to the nature of functional code and hardware graphics apis. it's super boring right now drawing stick men though so i had planned to do some react stuff with it
That’s legit.
@mitchelkuijpers yes, ctrl+click is lost. Wow, I needed to know this fact! Thanks, be shameless about possible bad practices that I may let out here 🙂
I will 🙂 @hlolli
@sophiago: props needs to be a JS object. E.g:
(dom/div #js {:className "foo"
:style #js {:color "red"}})
@anmonteiro ah, thanks. i fixed that, but still think i must be doing something wrong with rendering here?
@sophiago your render code doesn't look correct
one sec
(defui slider
Object
(render [this]
(dom/input #js
{:type "range"
:id (get (om/props this) :id)
:min 5
:max 100
:step 1
:style #js {:width "360px"
:left (get (om/props this) :left)
:top (get (om/props this) :top)
:position "absolute"}
:onChange
(fn [e]
(swap! num-sliders assoc :n e.target.value))})))
(you need to include a key for the :id
)
and I spliced :onChange
too
yeah, I didn't see that
fixed ^
also, (get (om/props this) :x)
becomes repetitive. I would do (let [{:keys [id left top]} (om/props this)])
but that's just nitpicking
wait, you didn't just mean that render did you? i assumed the factory render at the end? because i still don't see anything
i had seen that part done with js interop and also in a separate defui was what i meant
om.next app design question * my defui component renders based on window properties like scroll position and width/height etc--i imagine this is a very common thing for ppl to do * it seems silly to capture these and try to manage the state yourself--given that the browser's already doing the job! * ...but which means instead of updating your state on resize/scroll/etc events, you instead simply need to call (.forceUpdate this) does this sound like the right approach/idiomatic way to render based on dynamic browser window properties?
@sophiago oh I didn't even see that part 🙂
yeah you don't want to js/ReactDOM.render
add-root!
will do it for you
you'll want an explicit Root component too
what you're passing to ReactDOM.render
should be its own defui
that you pass to add-root!
so it's as simple as having the generator for my factory as its own defui and then adding that as the root component, right?
should be, unless you're doing something else not quite right that I haven't seen 🙂
probably (range :state)
should be (range (:n @num-sliders))
?
or :n
should even be in props
ah, see i just ran through the quickstart and was unsure how reconcilers worked. i thought part of it was managing state so you didn't need an explicit call like that
you don't, it should be in props
(sorry, moving a little slowly because today is the day everyone in my country is going a little off...woman got pushed in front of the subway right near me? people think it could be the end of the world)
@anmonteiro i feel bad bothering, but tried recompiling figwheel even and can't tell what i'm doing wrong with this first component since i'm not even getting error messages...just no rendering 😛
@sophiago (range :n)
= ()
empty list
you probably want (range (:n (om/props this)))
:n
is just a keyword
okay...getting something, errors from figwheel and an infinite loop. good sign at least 🙂 seems to possibly be due to string conversion inside props instead of the UI component itself
huh, fixed that and back where i started. looking in the chrome devtools inspector now to see if i'm missing something and should be breaking this down further
ah, ok. it's my call to js/window.innerWidth and js/window.innerHeight that are bad syntax
i think om.next got me thinking back in terms of prototypal syntax because of how it mixes some things up, but then i also got the sense that wiki is a work in progress and some of that js interop has been supplanted as best practice (like how i was initially rendering...guessing you probably don't want to do that even in the simplest cases where it works fine?)
thanks @anmonteiro !
np, glad it works
"react.inc.js:20483 Warning: Constructor is changing an uncontrolled input of type range to be controlled. Input elements should not switch from uncontrolled to controlled (or vice versa). Decide between using a controlled or uncontrolled input element for the lifetime of the component."
I think you just need to provide a :value
to the input
yeah, take it up with the React people 🙂
ha. they could start by writing a tutorial that's accurate as of two years ago for starters
I think they just revamped the docs a few days/weeks ago
i mean, their api docs are fine. it's the tuts people coming straight to it use that were that old
just the bar for open source is continually lowered i think at those large companies, for which i'd blame zero open source apple
react was only open by accident when they bought instagram and it had a different backend
anyway, my second question was not particular to om, so feel free if you don't have an answer offhand. but i'm wondering about the ideal way to benchmark cljs vs. js, obviously because i'd like to compare this to the js version
oh, i guess maybe i should also ask you as a contributor: one thing i'll probably want to port to om.next in a bit is a react component for hot swapping glsl shaders from template literals so should probably check whether something like that already exists and then if not if it would be something worth integrating to the library or how that would even work? or just as an example maybe? it's basically just a utility component and then i've toyed with doing actual glsl bindings for clojurescript, which i know some other people have been at various stages of working on as well. not sure whether i'd want to undertake that latter part, though
ah, and see there's a problem with specifying :value in the UI element because it essentially acts as its own constructor? in general since i start with a certain number in the atom those don't track the rest due to that. i can't imagine i'm explaining this well, but can't think of a better way without digging into how om.next wraps the react api, which i'd rather not because i'm quite pleased in having gone this route over the reagant api directly