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
but all the weird app structuring tools ā¦ not going to touch that stuff or support it
@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?