Fork me on GitHub
#om
<
2016-06-24
>
urbanslug10:06:53

Hello setCustomValidity isn’t recognised in om?

dnolen10:06:18

first part of the problem

urbanslug10:06:22

(js/setCustomValidity …)

dnolen10:06:26

:on-invalid is a proper event

dnolen10:06:46

we don’t use kebab case for events, the keyword should directly reflect the event name always

urbanslug10:06:12

you mean camel case?

dnolen10:06:21

it’s not even really a keyword just a syntactical thing for #js data literal

dnolen10:06:25

foo-bar is kebab case

dnolen10:06:34

fooBar is what you want

dnolen11:06:08

the other thing - what is setCustomValidity? a method? do you have link to something?

dnolen11:06:31

that’s a method - not a global js call then

dnolen11:06:22

(fn [e] (.setCustomValidity (.-target e) …) is probably more like what you want

urbanslug11:06:07

Thanks @dnolen 🙂 you’ve helped me a lot more than I expected.

martinklepsch11:06:07

Anyone know of any code that uses Reagent components inside Om?

martinklepsch11:06:43

I'm thinking since they're both React under the hood there should be some way to interop

anmonteiro12:06:28

@martinklepsch:

(defn reagent-comp []
  [:p "I'm reagent"])

(defui Root
  Object
  (render [this]
    (dom/div nil
      (dom/p nil "I'm Om Next")
      (r/as-element (reagent-comp)))))

(def reconciler
  (om/reconciler {:state (atom {})}))

(om/add-root! reconciler Root (js/document.getElementById "app"))

martinklepsch12:06:18

@anmonteiro: thanks! as-element unfortunately only works for simple components (render functions)

martinklepsch12:06:50

also not too important but this is about Om.Now not Next

anmonteiro12:06:35

@martinklepsch: I’m not too familiar with Reagent, but maybe reagent.core/reactify-component would work?

martinklepsch12:06:08

Hm, that equally seems to work only for simple components

yusup12:06:13

Hi,what is the correct process for editing Om Wiki ?

martinklepsch12:06:09

or maybe it works, need to do more digging 🙂

mitchelkuijpers13:06:36

@martinklepsch: we are movin from re-frame to om.next and reagent/as-element works fine also for not so simple elements it even works with components that have subscriptions etcetera

mitchelkuijpers13:06:46

We use it like this

mitchelkuijpers13:06:50

(reagent/as-element
           [autocomplete/multi-dropdown
            {:name "columns"
             :confirm-submit? true
             :alignment :right
             :fixed-text (get-text :entity-table/drop-down-columns)
             :on-change change-fn
             :selected active-columns
             :choices (concat builtin-fields columns)}])

martinklepsch13:06:19

@mitchelkuijpers: ah, interesting, didn't consider wrapping it in a vector

martinklepsch13:06:46

@mitchelkuijpers: what brought you from re-frame to om.next?

mitchelkuijpers13:06:47

Our application was getting bigger and bigger and we were building our own normalization and fighting with getting all the data at once. And in general we wanted a more constrained way of building our UI

mitchelkuijpers13:06:05

I really like the part where you define queries of what you need, this documents so much

mitchelkuijpers13:06:02

And of course we were building Rest services to get our data, which breaks down the more special stuff you want to do.

mitchelkuijpers13:06:46

@martinklepsch: And om.next feels like a better way to structure your application especially the removal of al the globals. This way we can start using devcards again

martinklepsch13:06:02

@mitchelkuijpers: thanks, I'm doing all this in an old Om codebase so Om.Next is an obvious contender but so far it hasn't convinced me. The getting all the data at once does seem handy but in our case server side rendering is better suited. It's less of an app where you interact with hundreds of things....

mitchelkuijpers13:06:15

@martinklepsch: For us it’s especially handy because we have certain object that get used in multiple places in the app and we had a lot of thins where they were outdated because somewhere we held 2 or 3 different lists

martinklepsch13:06:45

I have seen cellophane in fact and it does look good :+1:

martinklepsch13:06:23

Not sure I understand the issue described above, isn't that easily solvable with a shared subscription?

anmonteiro13:06:30

@cmcfarlen: definitely. good catch

cmcfarlen14:06:30

@anmonteiro: thanks! 🙂 Looking at the [:default :default] mutate too. Could it just pass the output of the user-parser directly?

cmcfarlen14:06:44

err, return* the output

cmcfarlen14:06:02

I have one mutate fn that targets a different remote and I modify the params of the ast

mitchelkuijpers14:06:23

@martinklepsch: We have an entity that comes from a /search endpoint and something that comes from a /list endpoint en something from a /entity-by-id endpoint somehow those 3 should stay te same. We should have fixed this by normalization but we didn’t but this is easily solvable

anmonteiro14:06:49

@cmcfarlen: that’s also probably a good idea

anmonteiro14:06:47

@cmcfarlen: patch welcome if you wanna take that upon yourself

cmcfarlen14:06:31

@anmonteiro: Sure, I'll try it out with my use case if I can to make sure it pans out.

anmonteiro14:06:51

make sure to include a test, please

cmcfarlen14:06:12

Is there a similar feature of boot to leiningen's checkouts feature?

anmonteiro14:06:29

what is lein’s checkouts feature? 🙂

anmonteiro14:06:33

Oh, I see what it is now

cmcfarlen14:06:36

If you have dependencies "checked out" in a subdirectory of your project called "checkouts" then those projects classpaths are included such that the code will be found first

anmonteiro14:06:37

hrm, not that I’m aware

anmonteiro14:06:44

but I’m just beginning to use Boot in my projects

cmcfarlen14:06:57

yeah, I had to install it to build compassus! haha

martinklepsch14:06:35

@mitchelkuijpers: ah so you stored responses as they were {:search [] :list [] :by-id {}} instead of immediately turning them into a normalized structure, y?

anmonteiro14:06:40

you can probably use boot jar target -d checkouts

anmonteiro14:06:52

@cmcfarlen: ^^

mitchelkuijpers14:06:56

@martinklepsch: jep -_-

anmonteiro14:06:05

and then include checkouts in your source-paths or something

anmonteiro14:06:18

there’s probably a better solution but I’d ask in #C053K90BR

cmcfarlen14:06:09

I might do just that. I lean pretty hard on that feature when working with cutting edge code!

martinklepsch14:06:24

@anmonteiro: @cmcfarlen there's a checkout task in <2.6.0 and a checkout option in >2.6.0

anmonteiro14:06:11

@martinklepsch: hah! there we go, thanks

martinklepsch14:06:18

boot checkout -h for the task version, can't find the right documentation for the option right now

anmonteiro14:06:32

-c --checkouts SYM:VER Add checkout dependency (eg. -c foo/bar:1.2.3).

anmonteiro14:06:38

checkout option ^^

cmcfarlen14:06:12

That looks really nice actually.

cmcfarlen14:06:54

I think I'll still have to glue it to leiningen's checkouts somehow though

anmonteiro14:06:27

@cmcfarlen: I’m happy to fix it if it’s too much trouble

cmcfarlen14:06:36

@anmonteiro: If you want 🙂 I don't know if I'll be able to get into it today anyway unfortunately.

anmonteiro14:06:56

@cmcfarlen: I have a little bit now, I’ll just get it out of the way

cmcfarlen14:06:15

Great! In other news, transacting the route parameters from pushy into the app state worked perfectly. So much so I'm going to move a whole bunch of query params into the app state.

anmonteiro14:06:26

@cmcfarlen: yeah, I like that option better too, as it really adheres to the “single source of truth” opinion