This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-10-22
Channels
- # admin-announcements (29)
- # aws (2)
- # beginners (25)
- # boot (110)
- # business (15)
- # cider (39)
- # cljs-dev (3)
- # clojure (90)
- # clojure-czech (28)
- # clojure-hamburg (1)
- # clojure-japan (24)
- # clojure-poland (149)
- # clojure-russia (46)
- # clojure-sg (9)
- # clojure-uk (6)
- # clojure-ukraine (1)
- # clojurescript (105)
- # core-async (37)
- # cursive (9)
- # dato (7)
- # datomic (6)
- # emacs (10)
- # events (1)
- # hoplon (22)
- # jobs (4)
- # ldnclj (38)
- # leiningen (4)
- # off-topic (17)
- # om (173)
- # onyx (134)
- # re-frame (46)
- # reagent (35)
Can anyone give me advice about autosizing textarea? I use TextAreaAutosize component, it do what needed (auto resizing), but every time I type something there is a problem. First symbol from input takes a right position, but then caret position moves to the end of textarea. i use Reagent (reset atom value), but I think it can be some trivial error with React interop.
I have a feeling that :window/size [1920 1200]
inside the examples might be related to me asking about something very similar a bit too often 😛
I have a working om-next component with a simple query. It’s the root component in the app. What do I have to do if I want to wrap it in a parent component?
If I just do
(defui MyRoot Object (render [this] ((om/factory MyQueryComp))))
, and use that as root,
I get an exception Uncaught #error {:message "No queries exist for component path (maps-fun.core/MyQueryComp)", :data {:type :om.next/no-queries}}
Sorry, to be more precise, I have it working as a root, but instead I want to wrap it in another component.
'(defui Person
static om/Ident
(ident [this {:keys [name]}]
[:person/by-name name])
static om/IQuery
(query [this]
'[:name :points]))
(defui RootView
static om/IQuery
(query [this]
(let [subquery (om/get-query Person)]
`[{:list/one subquery} {:list/two subquery}])))'
@dnolen: It’s just a matter of nesting a non-nested component, Foo. First, it’s the only component and thus the root, and the query works fine. Then, I try nesting it in some trivial component (like (defui MyRoot Object (render [this] (dom/div nil ((om/factory Foo))))))
) and it suddenly gives me an exception related to the component path
That gives me an exception Uncaught #error {:message "No queries exist for component path (maps-fun.core/Foo)", :data {:type :om.next/no-queries}}
and I’d like to add a “view” (now a UI view, but like a data view) over that state, to have for example a piece of data called active-section, where that is the first of thes ections which has :active true
same goes for users, I have a list of them and I’d like to have a :current-user which is just a user that has :authenticated true
@txus that’s actually very easy to do om-next-demo has an example of that, i.e. the currently editing thing is exactly the same problem
in general you’ll find little in the way docs, I’m too heads down fixing bugs and wrapping up the design
there’s some community effort happening here which will probably find it’s way back eventually
@dnolen: I see in the example that your source of truth is a piece of data called :todos/editing
, and then you project that into the todos when fetching them, assoc’ing :todo/editing if it’s the one. So you would recommend to have a separate piece of state, such as app/current-user {:user/id “827348728”}
, to keep track of the current user right?
in the case of editing, it’s safety measure that guarantees only one thing could every be edited
I went with that approach then now for some reason the reconciler doesn’t seem to normalize my data, but I probably messed something up
this is the source of my statement Single Atom + Reified Mutations + Property Based testing = OMFG
no more “UI is too complex to apply real testing techniques to it so we’re going to hire a bunch of QAs”
if you keep the button handlers to simple state changes, which is encouraged in om, clicking =~ om/transact!
and om/transact! you can automate, so there is almost no possible weird cases you cannot automate
you can now test that all friend lists are changed, that all friend counts are augmented
and a couple of api things may change, but they will probably be of the search/replace variety
that’s alright though, I’ll be on top of it for the next few months! my current client is pretty sold on om for almost everything UI, with plain React as a fallback
@txus did you actually go through the wiki bits? Definitely recommended if you haven't
yeah, they weird bit is that I pass in just data, and part of the data seems to be normalized in some calls to read
, and part of it doesn't
normalization is not automatic, your query and the UI components provide necessary information for that process
just to make sure, if I have this data: {:app/sections [{:section/id :foo, :section/name :bar}], :app/current-section {:section/id :foo}}
, is it enough that the current section references just the id?
{:app/sections [{:section/id :foo, :section/name :bar}], :app/current-section [:section/id :foo]}
it’s just a convention to make it simpler to do transactions and and projections on the client
is there a way to add a property to an om/next React class in defui (eg. childContextTypes)?
and no plans for that either, would need a lot of rationale to venture into allowing fields which are not props or state.
@mhuebert: also stuff like that is machinery that Om can provide itself and has in the past (very similar to shared)
about the only thing we do is make sure that pure reusable React components can be dropped in
@dnolen ok. I’m about to use the om/next reconciler / state-handling stuff for the first time and I’m sure things will be clearer in a few hours. I love the fact that defui outputs a plain React class & that all the lifecycle methods are easy to access - I had loads of trouble with all the various wrappers and all of those headaches have already vanished.
the fact that you can always get at the whole UI data tree is not something we’re going to part ways with
+1 for not interested in data hiding. It feels like a heavy burden is lifted from my shoulders when I don’t have to worry about that.
I do Om tutorials at night and then enterprisey monolithic framework server heavy jsp code during the day so I want to write an article comparing the two approaches. Also, an "Om for Enterprise devs" would be a really interesting talk. It's never too early to start working on the proposals for next years conferences
(inc <@U050C3ZHQ>)
In Om Next: There is nothing technically preventing query parameters from changing the query structure (instead of just going into the grammar as parameters). From Quickstart: "The params method should return a map of bindings. These will be used to replace any occurrences of ?some-var in the actual query." Is the API intention that (set-params!) be used to change things that are targeted at parameters in the query grammar, and (set-query!) should be used when you want to change the structure? Or is it free-for-all whichever you need for the use-case? I can definitely see cases where you'd want some portion of the query to change (add in a join), such that using a parameter would be more surgical...though it is a bit of a misnomer.
yeah, I could tell that from the source...just making sure there wasn't anything in the plans that would break that.
Yep. Just making sure you were not planning on making set-params! do something that would cause things to break if they were used in a non-params part of the query grammar.
the whole point of mutable set params & query is that recovers full dynamism if required
I'm building docs around playing with the queries, and I don't want to mis-state how things are "meant" to work
Yep. I totally get it. Just being careful with names of things when explaining them.
While the most pleasant way to do that kind of testing is headless I enjoyed the video I saw somewhere of someone's browser UI iterating through all the potential states their property-based tests were generating.
@zane right but are you doing headless testing with React by looking at the DOM or something else?
Right now I'm not doing either. If I were to try it I'd just test the state transition functions on bare data.
ok so I think I may have fixed the obvious problems with set-state!
tire kicking of master welcome
naming suggestions welcome https://github.com/omcljs/om/issues/435
Hey David, I'm seeing React warnings when I add getInitialState as a method under Object: Warning: getInitialState was defined on om_tutorial$core$ItemViewer, a plain JavaScript class. This is only supported for classes created using React.createClass. Did you mean to define a state property instead? that a known thing? Or am I doing it wrong?