This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-05-16
Channels
- # admin-announcements (3)
- # arachne (9)
- # beginners (10)
- # boot (56)
- # cider (4)
- # cljs-dev (5)
- # cljsjs (4)
- # cljsrn (3)
- # clojure (146)
- # clojure-austin (9)
- # clojure-greece (3)
- # clojure-poland (14)
- # clojure-russia (1)
- # clojure-uk (19)
- # clojurescript (46)
- # cursive (16)
- # datomic (21)
- # emacs (38)
- # events (2)
- # flambo (1)
- # garden (3)
- # hoplon (41)
- # jobs (1)
- # keechma (87)
- # off-topic (2)
- # om (62)
- # om-next (4)
- # other-languages (7)
- # pedestal (6)
- # protorepl (1)
- # reagent (3)
- # rethinkdb (1)
- # ring-swagger (1)
- # rum (3)
- # spacemacs (2)
- # specter (12)
- # test200 (2)
- # untangled (12)
@dnolen: using get-rendered-state
got me thinking if it would be possible to have it expose the same API as get-state
, namely the possibility to express an extra k-or-ks
argument
@anmonteiro: yes, I don’t recall why I didn’t do it that way
@dnolen: probably just an oversight. I’ll get on it
anyone know of any tutorials for making a simple chat app with om? wanting to follow one to learn
@biscuitpants: Not that I know of. I always recommend the Kanban demo for a 'whole application'. Plus you will find a few simpler ones, and of course there's the tutorials which have small applications in them.
@tony.kay: Hi, I tried to run your tutorial from the cider cljs repl but, while it started the browser didn’t connect properly. I am running it from a lein repl and everything works fine (except I am missing some cidery goodness). Is that a known thing, or does it sound like I am doing something wrong (again)? Thanks
Is there a way to define statics in Om.Next defui
like this?
class SecondTabScreen extends Component {
static navigatorStyle = {
drawUnderTabBar: true
};
...
@madvas: static fields instead of functions?
or are you referring to inheritance?
your example would be the following in Om Next:
(defui SecondTabScreen
static field navigatorStyle #js {:drawUnderTabBar true})
(shouldComponentUpdate [this next-props _]
(let [next-props (gobj/get next-props "omcljs$value")
next-props (cond-> next-props
(instance? om/OmProps next-props) om/unwrap)
false))
What do you mean with vary?
have you seen default-ui->props
?
@denik: that’s expected, and known
in the reconcile!
function, we feed unwrapped props to sCU, but they’re wrapped in nested components
it’s just one of the painpoints of integrating with React
and CLJS’s persistent data structures
I’m not sure
I mean, the default implementation does exactly what you pasted
@tomayerst: I'm using Cursive w/IntelliJ. Don't use Cider, so I cannot really help. You might look at a recipe project file in the untangled-cookbook. Some of the guys on the team use CIDER, and I think most of the Untangled projects are set up to use it correctly. I'm not currently doing much directly with the Om tutorial at the moment. Feel free to submit PRs to make it better.
@anmonteiro: right, that’s what’s throwing me off. It does not seem to work.
@denik: I assure you it works, I’ve been using it in my projects too
you must be doing something wrong. What’s the problem you’re having?
@denik: right, but you pasted a solution for that
which is what we use in Om too
@anmonteiro: yep I pulled it out of defui because it did not work for me. So I’m wondering if this is maybe a bug in defui.
@denik: I don’t think the story for sCU is polished for user customization
This is more of a React question really, but is there ever a reason to use a <form>
in an Om/React app? I notice we're doing a lot of (.preventDefault %)
in our button click handlers to keep forms from submitting normally, and I wonder if we should just replace the <form>
s with <div>
s. Are there semantic/accessibility reasons to use a <form>
even in such a controlled system?
@anmonteiro: okay leaving it at that 😉
@peeja: even before React, I’ve always had to call preventDefault
on form submission
Well, I don't know what you were using, but before React I was mostly using jQuery and my jQuery code actually interacted with the <form>
elements in the DOM
That was a world of progressive enhancement, so I tended to have real <form>
s that could actually submit if JS were turned off
@peeja: right, I meant when doing AJAX calls
maybe jQuery handled that for you, but there has always been preventDefault
under the hood
what I’m getting at is that this would be no different in React than it was before
No, I mean, I had to do that manually, but it seemed reasonable then, because I wanted it to degrade to a normal HTML form
gotcha
In our case, we've got <form>
elements around a lot of our "forms", but the element doesn't have an action set, so it wouldn't do anything useful if the browser actually submitted it
@peeja: besides the HTML semantics I don’t really see any benefit then, but I haven’t given it a lot of thought 🙂
Yeah, that's what I'm wondering about now: does the browser use those semantics for something subtle I'm not thinking of that I'd lose? Maybe accessibility stuff somehow?
Found an answer to my question: pressing enter in a field in a form performs a click event on the default button of the form.
The <form>
helps the browser decide which button to click; without one, it won't click any button.
I'm having trouble wrapping my head around om.next queries. Suppose I have a defui
which represents/displays a list of strings, and I want the user to be able to sort it in either ascending or descending order. What's the idiomatic way of representing this as a query?
Ideally this query is going to be sent to the server and interpreted/executed there. It seems like this is the sort of thing update-query! is made for.
So this component renders a button. When clicked, it will update the component's query. Should it call set-query!
directly, or should it call om/transact!
, and have the reconciler's mutate function call set-query!
?
It seems like the latter is what I'm "supposed" to do, but it also seems appropriate that query mutations be on the defui
close to where the query is defined.
I’m working through the om.next quick start (https://github.com/omcljs/om/wiki/Quick-Start-(om.next)) and I am stuck at the end of the ‘Checkpoint’ section with an exceed max line 4096
error when I try to load localhost:3449. I’d appreciate any insights on what may be going wrong here.