This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-02-28
Channels
- # aws (7)
- # beginners (69)
- # boot (67)
- # cider (9)
- # cljs-dev (159)
- # cljsrn (2)
- # clojars (25)
- # clojure (345)
- # clojure-austin (9)
- # clojure-berlin (1)
- # clojure-dusseldorf (10)
- # clojure-italy (3)
- # clojure-nl (1)
- # clojure-portugal (1)
- # clojure-spec (73)
- # clojure-uk (59)
- # clojurescript (163)
- # clojurewerkz (1)
- # component (26)
- # core-matrix (2)
- # cursive (20)
- # datascript (32)
- # datomic (15)
- # dirac (16)
- # emacs (3)
- # hoplon (35)
- # jobs-discuss (87)
- # jobs-rus (95)
- # luminus (15)
- # om (135)
- # om-next (3)
- # onyx (47)
- # pedestal (67)
- # perun (74)
- # play-clj (4)
- # portland-or (1)
- # proton (4)
- # re-frame (13)
- # reagent (18)
- # remote-jobs (17)
- # rum (20)
- # specter (11)
- # untangled (101)
- # yada (18)
@qqq I think I mostly understand your question since I had similar questions when I was just starting out with om.next and I think the answer is “it depends” on 1. performance 2. elegance/proper way to store state
So SVG does NOT support slider bars, which means I' implementting them myself (since foreign object is broken).
So what I'm not sure about is: * the slider location * the "view port" ^^ should the above be global state or local state ?
but DO NOT transact WHILE the animation/draggin is happening since that might case way too many re-renders depending on the case
@raspasov: mouse-move = updating local state mouse-up = do transact so the problem with this is that as I'm dragging the slider around, I need the content inside the window to pan -- this means hacky callbacks + more local state ?
and just fyi my experience with om.next is mostly with React Native/mobile so it might not apply to your case
by "transitive" do you mean "stuff we don't care about if we close the browser an dlose it" ?
this seems awfully hacky, for the slider to do a callback to the parent, which then tells anotther element "yo, change your viewport"
alright, as hacky as this is, I think this is the optimal solution; thanks for your insights
your callback at the end of the drag can just directly om/transact! into the global state, no?
as I'm moving the slider around however, I need the displaybox to pan -- so I need a callback there
I would try both ways and see if it makes any difference with performance/smoothness/ux etc
Window:
* Title Bar
* Vert Slider
* Actual Content Box
so when I'm dragging over the VertSlider, I need to use local state to update the location of the slider (to display to the screen)
however, I also need to pan the contents of Actual Content Box
and I believe that requires a callbackalso if something is affecting the smoothness of animation there’s om/react-set-state!
react-set-state! is different https://github.com/omcljs/om/wiki/Documentation-(om.next)#react-set-state
"Perform a stock react setState! outside of the om.next "render loop". Useful for preventing state changes from interrupting animations."
yes, it’s an optimization but it can be very useful in some cases to prevent choppy animations
Hi. Once upon a time I asked about the status of om.next, and by now I see there's already actionable documentation and stuff. Anything I should know about stability and completeness, before getting hands dirty?
@matan It's probably not a good idea to use datascript, stick with an atom. Otherwise, officially still alpha but pretty stable and complete. I'm writing a production app in it and haven't hit any blockers.
@danielstockton : I'm just in the process of switching to datascript
@danielstockton : what issues did you run into with datascript?
I say that because set-query! doesn't work. It's possible to do everything without set-query! though.
You are also not going to be able to use compassus and possibly other libraries, although it isn't too hard to roll your own routing.
I really wanted to use datascript but it seems like an afterthought at the moment.
I like datascript's query language + transact! model for adding stuff more than I like om.next/s model for querying/adding stuff
I think it's only set-query!
that has problems because it stores the queries in state, which it assumes to be an atom.
I wanted to submit a patch to allow storing queries in different state containers but I wanted guidance to increase chances of it being accepted and not sure there is much interest in it at the moment.
I know 😉
Maybe you'd like to +1
it's actually not clear this is a problem with datascript since I can just pass the extra argument as a param, and have d/q handle it
in standard om/next, we want "dynamic queries" since IQuery has to return the actual query
but with datascript, what IQuery returns is an argument that some function consumes before writing a d/q query
It's not a problem with datascript. It's a problem with om, because it has to remember what the new query is somehow and at the moment it can only store it in the state (atom).
I'm trying to say: if you're using datascript as backend, you can get dynamic queries even now
because we don't run d/q directly on what IQuery returns; but we have a layer of indirection to process it to decide what to feed to dq
You can yes, outside of the set-query!
mechanism.
That's what I meant to say earlier with "It's possible to do everything without set-query! though." You can update the state directly and handle everything in the parser.
Ah, I see now. Sorry for this, I started using om next 3 days ago and datascript 6 hrs ago, so all is new to me.
I just like to point it out because it's not documented anywhere and set-query!
is quite a commonly seen feature.
hey guys, is there a way to store a om/transact’s uuid in a var, so it can be used later? In my test I need to take state before the mutation and after, compare it and make assumptions
@ag there might be a better way
I was thinking if I there’s a way to do something like
(let [t (om/transact! ,,,,
before (om/from-history t)] )
@anmonteiro I’m all ears
this landed in the latest alpha (48) https://github.com/omcljs/om/commit/ee7f9f60da20a1d5e4ee1b4dbcf8f7a709d833c5
you’ll get the old-state and the new-state handed out to you 🙂
for every transaction
thanks @anmonteiro !
@anmonteiro can you advise me now how deal with this "level of indirection”, in tx-listen I compare and do assumptions, but I need the assertions outside of that.
hrm so probably tx-listen
is not what you’re looking for
e.g.:
(defscpec mutation-test
(prop/for-all [gen-data my-gen]
(let [reconciler (om/reconciler {:tx-listen (fn [env tx] ,,, check )) :state gen-data}
;;; what now?
))
is this only for writing generative tests?
I wouldn’t use om/transact!
in generative tests
just build a parser and call it directly
I think we need to take a step back
Om Next abstracts things in the parser for a reason
so my question is why would you want to break that abstraction?
so, I need to test mutation, right? The best way of doing that is to compare the state before and after mutation, right?
OK so then we go back to what I was trying to say
mutations are just data
so just construct a om.next/parser
and pass it some mutation data
you can choose what state you pass to the parser call
and you can hold on to a deref of that thing before you call the parser so you can do comparisons later
is there anything I’m missing?
so you’re saying that I don’t really have to call om/transact! in order to test the mutation?
@ag did you ever read this? ^
right
since transactions are eventually fed to the parser
so just test the stateless part of your system
so, let’s say I have ux-table, and a mutate let’s call-it sort!
I need to test how it works, when it’s transacted it should change things in the state, let’s say it adds information about which column is sorted
maybe this is what you’re missing
when you call (transact! this [(launch/missiles!)])
, the transact!
function will eventually call (parser your-env-including-state '[(launch/missiles!)])
so you can just call the parser yourself
with the tx
and whatever environment you want there to be
(let [state (atom {:foo :bar})
parser (om/parser {:read … :mutate …})
old-state @state]
(parser {:state state} '[(some/mutation! {:mutation :args})]))
;; test new-state -> @state
@ag is this clearer? ^
what are you still missing?
om/parser has in my opinion equal corrolation between lack of documentation and lack of users knowledge, in inverse ratio to it's importance.
I don’t disagree
in my company Im learning re-frame, because majority voted against om.next. I'm filled with disappointments about how fanatical some of the re-frame users can be about the features they have, when I'm shaking my head thinking "it's all possible/done the same in om.next with less fancier names, less fancy readme and less hyped technology".
I don't say fanatical. But I believe there's much misunderstanding surrounding om.next, that became very clear to me on last :clojureD. Maybe I write an article about the parallels between om.next and re-frame when I've got the juice of re-frame.
Reframe and Reagent were the first React frameworks I got to use when I started learning Clojurescript a few months ago. And it felt nice.
Now every day I have these moments when I feel like “wow, this is so AWESOME!”. And sometimes I feel completely lost
I feel like programming om is like playing golf, one hole it's the most fun sport in the worl, the next hole I throve my driver into the river and leave the course.
Personally I wouldn’t be working with om if it weren’t for #untangled, I don’t think I would want to work with something that has to make your write your own parser to get a web application going.
I disagree, but then again, it’s the thing about personal opinions
having the ability to write parsers a la carte is, among other things, what makes Om’s testability so great
it’s also what allowed us to do a lot of fancy stuff at Ladder and it’s part of what I’m gonna be talking about at Clojure/West 🙂