Fork me on GitHub
#om
<
2016-05-16
>
anmonteiro12:05:56

@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

dnolen12:05:11

@anmonteiro: yes, I don’t recall why I didn’t do it that way

anmonteiro12:05:56

@dnolen: probably just an oversight. I’ll get on it

biscuitpants14:05:01

anyone know of any tutorials for making a simple chat app with om? wanting to follow one to learn

cjmurphy14:05:00

@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.

tomayerst15:05:16

@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

madvas15:05:25

Is there a way to define statics in Om.Next defui like this?

class SecondTabScreen extends Component {
  static navigatorStyle = {
    drawUnderTabBar: true
  };
...

anmonteiro15:05:40

@madvas: static fields instead of functions?

anmonteiro15:05:35

or are you referring to inheritance?

madvas15:05:50

not inheritance, just to assign static property to underlying react class

anmonteiro15:05:35

your example would be the following in Om Next:

(defui SecondTabScreen
  static field navigatorStyle #js {:drawUnderTabBar true})

madvas15:05:23

wow thanks a lot!

denik16:05:54

the next-props from`shouldComponentUpdate`vary

denik16:05:59

had to resolve this with

denik16:05:00

(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))

denik16:05:35

may be a bug in defui

iwankaramazow16:05:13

What do you mean with vary?

iwankaramazow16:05:24

have you seen default-ui->props ?

anmonteiro16:05:05

@denik: that’s expected, and known

anmonteiro16:05:43

in the reconcile! function, we feed unwrapped props to sCU, but they’re wrapped in nested components

denik16:05:05

and you do that in order to?

anmonteiro16:05:43

it’s just one of the painpoints of integrating with React

anmonteiro16:05:51

and CLJS’s persistent data structures

denik16:05:16

I see. This could be taking care of conditionally in defui, right?

anmonteiro16:05:59

I’m not sure

anmonteiro16:05:18

I mean, the default implementation does exactly what you pasted

tony.kay16:05:19

@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.

denik16:05:15

@anmonteiro: right, that’s what’s throwing me off. It does not seem to work.

anmonteiro16:05:12

@denik: I assure you it works, I’ve been using it in my projects too

anmonteiro16:05:24

you must be doing something wrong. What’s the problem you’re having?

denik16:05:00

exactly what you said: sometimes next props are a cljs map and other times a js obj

anmonteiro16:05:28

@denik: right, but you pasted a solution for that

anmonteiro16:05:31

which is what we use in Om too

denik16:05:11

@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.

anmonteiro16:05:02

@denik: I don’t think the story for sCU is polished for user customization

peeja16:05:01

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?

denik16:05:14

@anmonteiro: okay leaving it at that 😉

anmonteiro16:05:36

@peeja: even before React, I’ve always had to call preventDefault on form submission

peeja16:05:55

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

peeja16:05:27

That was a world of progressive enhancement, so I tended to have real <form>s that could actually submit if JS were turned off

anmonteiro16:05:42

@peeja: right, I meant when doing AJAX calls

peeja16:05:45

and then I'd override the submit with JS to do something AJAXy

anmonteiro16:05:29

maybe jQuery handled that for you, but there has always been preventDefault under the hood

anmonteiro16:05:51

what I’m getting at is that this would be no different in React than it was before

peeja16:05:18

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

peeja16:05:42

But in React, nothing works without JS

peeja16:05:58

I suppose if I were doing isomorphic React on the server, that would be useful

peeja16:05:39

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

anmonteiro16:05:14

@peeja: besides the HTML semantics I don’t really see any benefit then, but I haven’t given it a lot of thought 🙂

peeja16:05:04

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?

peeja16:05:11

It may affect autocomplete…

dnolen18:05:11

cut 1.0.0-alpha35 with latest fixes

peeja20:05:07

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.

peeja20:05:32

The <form> helps the browser decide which button to click; without one, it won't click any button.

danburton21:05:09

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?

danburton22:05:59

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.

danburton22:05:01

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!?

danburton22:05:21

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.

jbranchaud23:05:13

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.