Hello setCustomValidity isn’t recognised in om?

first part of the problem

(js/setCustomValidity …)

:on-invalid is a proper event

hmm

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

you mean camel case?

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

foo-bar is kebab case

fooBar is what you want

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

http://www.w3schools.com/js/js_validation_api.asp

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

Really from http://stackoverflow.com/questions/10361460/how-can-i-change-or-remove-html5-form-validation-default-error-messages

Ok

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

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

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

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

@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"))

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

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

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

Hm, that equally seems to work only for simple components

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

or maybe it works, need to do more digging 🙂

@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

We use it like this

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

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

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

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

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

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

@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

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

Have you seen: https://github.com/ladderlife/cellophane

@anmonteiro: Should the key here be target instead of :remote? https://github.com/anmonteiro/compassus/blob/master/src/main/compassus/core.cljc#L146

@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

I have seen cellophane in fact and it does look good 👍

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

@cmcfarlen: definitely. good catch

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

err, return* the output

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

@cmcfarlen: fixed in master https://github.com/anmonteiro/compassus/commit/b759405c1ac0bd4b1aed0085020c8a8e46b3ebf0

@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

@cmcfarlen: that’s also probably a good idea

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

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

make sure to include a test, please

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

what is lein’s checkouts feature? 🙂

Oh, I see what it is now

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

hrm, not that I’m aware

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

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

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

you can probably use boot jar target -d checkouts

@cmcfarlen: ^^

@martinklepsch: jep -_-

and then include checkouts in your source-paths or something

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

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

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

@martinklepsch: hah! there we go, thanks

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

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

checkout option ^^

That looks really nice actually.

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

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

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

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

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.

@cmcfarlen: try master https://github.com/anmonteiro/compassus/commit/fb6ecb9e2a69734ad92d5651b8ecd7b3583e9fd3

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