Fork me on GitHub
#om
<
2016-09-26
>
levitanong06:09:31

@anmonteiro Why are the static methods explicitly checked for as in https://github.com/omcljs/om/blob/master/src/main/om/next.cljc#L318? With a more permissive filter, you can let users extend their components with things like static IStyle. This will allow one to have colocated styles and generate stylesheets during compile time instead of runtime. :thinking_face:

hlolli09:09:45

static IStyle, interesting. I need to find some new way of doing css with react components, since I use often material design, that have some many nested styling properties that css stylesheet cant target. So I end up writing clojurescript code that is 50% :style #js {..bla...} , bit ugly.

hlolli10:09:29

Has someone here implemented cljsjs.react-OnClickOutside? It seems to want to take in a react class, in other terms, I could then only give it a component as parameter but not element?

anmonteiro10:09:16

@levitanong: I was under the impression that it worked

anmonteiro10:09:47

Definitely unintended if it currently doesn't

levitanong11:09:45

@anmonteiro the server side version explicitly looks for IQuery, IQueryParams, and Ident. When I add my own protocol, it’s absent from the meta

levitanong11:09:56

@hlolli Have you tried implementing the feature from scratch? You can just add a window listener on mount to call some close fn when isDefaultPrevented, then .preventDefault on the component/element itself.

hlolli11:09:31

no haven't tought of that, was considering doing event listeners on all except the dialog I want to prevent the behaviour on. Simple problem, but tricky to solve. Is .preventDefault a native js function?

hlolli11:09:14

(doing event listener on "all except" I will try to avoid at all cost 🙂 )

hlolli11:09:30

ok, I found documentation about preventDefault, thanks for pointing this out, I see where this rabbit hole leads. But still curious to know how one would implement cljsjs-onclickoutside in OM. The docs look like this

// load the HOC:
var onClickOutside = require('react-onclickoutside');

// create a new component, wrapped by this onclickoutside HOC:
var MyComponent = onClickOutside(React.createClass({
  ...,
  handleClickOutside: function(evt) {
    // ...handling code goes here...
  },
  ...
}));
Looking like onClickOutside is a function to be called with js/onClickOutside, but that wont work. (actually the extern is OnClickOutside, to be percise).

hlolli11:09:07

I may guess I need (js/React.createFactory (js/React.createClass like with om.dom/wrap-form-element, I give that a try.

levitanong11:09:22

Hang on, making a snippet

hlolli11:09:11

hehe nice! this is easy! Thanks!

levitanong11:09:18

no prob 🙂

levitanong11:09:25

lemme know if you run into any trouble

hlolli12:09:35

@levitanong I guess I need to look further. After looking into .preventDefault and .stopPropagation, then they do work when I add them as special event listeners on specific dom target (on one document other one on dom that I want to prevent), but when happens instead is that the onClick Events that I do want to fire, are as well counted as "default". (sorry for the rest here about this bit offtopic discussion).

levitanong12:09:26

What I do is I place the .preventDefault in the outermost container of whatever needs to be immune to click-out. Anything inside it will be unaffected.

levitanong12:09:18

@anmonteiro Should I make an issue for the static protocol thing?

anmonteiro12:09:35

@levitanong probably, so I don’t forget

peeja13:09:45

@anmonteiro Oh, sweet! Thanks for the update! I'll give that a try.

wilkerlucio15:09:51

hello people, I noticed here that when a React component triggers a state update (think a non Om component), their children seems to lose the Om Next properties, making impossible to access the reconciler from those at this point

wilkerlucio15:09:58

here is an example code:

wilkerlucio15:09:32

on the first render the reconciler is correctly logged, but when the state is updated the render logs nil

wilkerlucio15:09:08

should I expect to lose the props on this situation?

hlolli16:09:02

Dont know how it works with js arrays, but you would at least want to implement read (static om/IQuery) on InnerElement. To read the keys being passed from react-container.

anmonteiro16:09:09

@wilkerlucio you shouldn’t expect that to work, no

anmonteiro16:09:50

should probably work with ^

anmonteiro16:09:04

if you omify your plain React component

wilkerlucio16:09:56

@anmonteiro thanks, I'll try that, currently my use case is trying to integrate the new React Router v4 into my app, it has a container <Router> element that does state transitions when the page changes, other than that their new approach to routing works very nicely with Om 🙂

anmonteiro16:09:40

@wilkerlucio I’d be interested in seeing a snippet of integrating RRv4 with Om Next

anmonteiro16:09:59

even though I don’t think it’s really a good fit for Om Next apps

wilkerlucio16:09:23

let me show you what I'm currently doing:

wilkerlucio16:09:25

I have this om-match that wraps RRv4 match, the major difference is that besides changing the component, it also triggers a change into the parent query

wilkerlucio16:09:04

then the component with the pages looks like this:

wilkerlucio16:09:45

@anmonteiro why you think the RRv4 is not a good fit for Om?

anmonteiro16:09:42

@wilkerlucio the way I see Om Next is that you have all your data separated from the UI

anmonteiro16:09:57

your render functions should be pure functions from your data -> rendered DOM

anmonteiro16:09:09

with RRv4 you’re just conflating everything

anmonteiro16:09:14

testability goes to hell

anmonteiro16:09:25

also, the moment you’re tying your business logic to the view logic, you’re losing the ability to just swap other views in and out

wilkerlucio16:09:14

@anmonteiro I'm not sure if it's possible, but what if we could just integrate the router state into the app state? it seems to be just about listing to it and converting into data at the app state, maybe creating a new custom Router (they have a few of those available on RRv4)

wilkerlucio16:09:59

I just really like their new approach, seems so much simpler to use and understand IMHO

anmonteiro16:09:01

@dnolen OK to request one more alpha after you review those 3 outstanding PRs?

dnolen16:09:41

@anmonteiro yes will try to get to that later today

anmonteiro16:09:48

awesome, thanks

anmonteiro21:09:50

let me know if you want me to cut a pre-release or something

anmonteiro21:09:05

still a few things that I got planned before actually cutting a proper one

peeja21:09:59

We should be good with some workarounds until you're ready to release for real, no need to cut a pre-release. Thanks, though!

anmonteiro21:09:03

@peeja currently thinking about hooking :history into 2 separate mixins

anmonteiro21:09:16

basically :will-mount and :will-unmount

anmonteiro21:09:34

since :history is currently not specific at all to history 🙂

peeja21:09:16

Oh, neat, that makes sense

anmonteiro21:09:33

also happy to hear more feedback

dnolen21:09:39

1.0.0-alpha46 released

anmonteiro21:09:51

@peeja btw all your Om workarounds should be obviated by this new release ^

anmonteiro22:09:02

mostly driven by the bugs you found recently 😄

peeja22:09:06

Awesome 🙂

grzm22:09:22

Anyone seen any "incomplete alias created for namespace" warnings when upgrading to alpha45? I haven't drilled down into what's causing it, but I can confirm that the commit that the warning starts showing up with the server-side rendering support commit. No change in my application code.

grzm22:09:29

The full warning is

WARNING: ...resources/public/js/prod/cljs/analyzer.js:4698: WARNING - incomplete alias created for namespace cljs.spec
var mchk = (function (){var and__54983__auto__ = cljs.spec;
                                                 ^

anmonteiro22:09:58

@grzm probably driven by also upgrading CLJS?

grzm22:09:12

Nope. Same version of CLJS ("1.9.229")

anmonteiro22:09:28

weird. same in alpha46?

grzm22:09:04

Gonna check that right now.

grzm22:09:50

Yup. Same in alpha46

grzm22:09:25

I see it under advanced compilation

anmonteiro22:09:28

@grzm oh, only under advanced?

grzm22:09:54

I believe so. I'm currently trying to work up a test-case.

anmonteiro22:09:33

hrm, I wonder if it happens in CLJS 1.8.51

anmonteiro22:09:41

(last release before incorporating cljs.spec)

anmonteiro22:09:55

Could be something that’s not completely baked into ClojureScript yet

anmonteiro22:09:16

or maybe you’re actually using cljs.spec and cannot test that 😛

grzm22:09:32

Yeah, I'm happily using cljs.spec 🙂

grzm22:09:21

Interesting that I'm seeing it with the om upgrade. Some sort of weird interaction, I suppose

grzm23:09:55

Kinda surprised a script that doesn't do anything even compiles to something that isn't empty 🙂

anmonteiro23:09:27

can you repro without Om?

anmonteiro23:09:40

maybe with a .cljc file, IDK

anmonteiro23:09:47

probably worth raising a JIRA in anycase

grzm23:09:16

Maybe, but I'm at a loss as to how. I don't know what in the server-side rendering commit is triggering the warning. Taking om.next out of the require makes the warning go away.

grzm23:09:10

I'll open a ticket.

anmonteiro23:09:58

@grzm right what I think changed was moving from a .cljs and .cljc files for the om.next namespace to a single .cljc file

anmonteiro23:09:14

but I have no concrete evidence that’s what caused it since the commit was a pretty big change

grzm23:09:26

Yeah, I noticed 🙂

grzm23:09:57

I forgot how much I missed JIRA! 😉