This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (49)
- # bangalore-clj (1)
- # beginners (56)
- # berlin (1)
- # chestnut (6)
- # cljs-dev (5)
- # clojure (48)
- # clojure-greece (29)
- # clojure-russia (3)
- # clojure-spec (5)
- # clojure-uk (3)
- # clojurescript (28)
- # cursive (25)
- # emacs (3)
- # fulcro (123)
- # hoplon (2)
- # klipse (6)
- # off-topic (146)
- # om (11)
- # re-frame (29)
- # reagent (7)
- # reitit (3)
- # specter (11)
- # unrepl (4)
- # yada (3)
@wilkerlucio My bad…I just had not pushed those branches. The 2.0 versions of them on clojars were already right.
I just pushed an updated lein template that can optionally generate a 2.x app. I ran the tests, but need to go to bed. Tired. It may work…you get v2 with:
lein new fulcro project-name v2
for people trying Fulcro 2.0,
fulcro-inspect now is compatible with it, try the version
@tony.kay how can we focus a test on fulcro-spec? I can't find any examples on docs =/
:focused after the string of a specification
thanks, I found reading the specs later, my bad, I stopped reading on the description and didn't found it right there
but I think would be nice to have an example on the docs as well
unless there is one, and I'm blind and didn't see it XD
:focus there, nothing found
it says how to filter on the settings, but it's missing an example on
and there still the
serializable? one for us to look at 🙂
That one needed to get done, and I should have known that was your performance issue when you told me you had a blob of reframe data
it just means history could get hosed for support viewer…but I can consider that “your problem”.
but that was a different problem before
the issue on the basis only started today when I moved to 2.0
in the previous was something about the event cycle of the old om, probably something related to the
ah, sorry, I misread you, yes, what you said is right 🙂
and I agree it's the users problem if he starts throwing non-serialisable things there
I was going to suggest we make the check optional, but I'm ok with just dropping it too
I did a test dropping it here, man, the app is so fast now 🙂
with all the optimisations the transact! went from 1 full second to 3ms
@tony.kay just FYI, earlier I mentioned I was working on porting Fulcro Inspect over to a Chrome devtools extension. I did a spike of that and discussed the results with @wilkerlucio, we both agree that chrome devtools port is not worth the added complexity (and it will make developing fulcro-inspect much more annoying, 1 JS context becomes 5 and they communicate inconsistently with a mix of string-message passing and async calls).
@currentoor sounds fine to me. It is so easy to use with preloads
@wilkerlucio Is your optimization of the basis-time well-tested against queries of the difficult kind? Recursive? Unions? with parameters? Etc.
@tony.kay I added tests for the many cases I could think, including union (it uses all the options combined, not the best, but good enough), recursion with and without limits
yup, we can just ignore then 🙂
that’s why I put the check in. If you pass parameters like a react component, or accidentally return a value like a DOM element, then you hose history by accident
well, you would have to return that from the mutation, did you see that happening often?
I mean, in my experience what is mostly returned from the mutation is the entire app state, as a result of the last statement being a swap on the atom
I was thinking on that, is a Fulcro concern to store history? maybe it should be delegated to tools
can't the support viewer itself be a tool? so it could store whatever it needs in response to events
the tx is obvious, so I don’t mind removing the check for that…perhaps the answer is to NOT store the tx result
it is a tool, but the recording runs during normal user operation, and the view runs on the other side of the planet due to a support request on the serialized history
it’s useless if it isn’t serializable…putting it off on “another tool will do that” just kicks the ball down the road one step
yeah, but sometimes (like my case) I just can't afford that, yet, hehe
I'm ok with dropping those, or at least making it optional, because in my case it's an expensive thing
agreed…when I wrote it I knew it was too expensive…so, I think this is the right course.
well, it is only when you run a transact, so it is user-level frequency, so I thought maybe it would be ok…but since the return values are often accidentally the entire app state, it sucks
defmutation had an explicit return value that defaulted to nil, it would not be an issue
so, building and testing…I’ll push beta2 in a few once I’m sure I didn’t make a typo or anything
not sure if you read,
fulcro-inspect is working on 2.0
I loved that the merges now come on tx-listen
but I'm missing the
:sends, you removed those intentionally?
I don't see then coming on the TX info anymore
if we can get those back would be cool, unless you remember a good reason for removing then
so, they should be serializable…they are useful…yeah, don’t think I meant to remove them
- include network sends in history - basis-time optimizations - serializable checks removed
I think I remember now why I removed sends…nothing was using them at the time. Support viewer didn’t have a good way to show them. So, I figured I’d add them when they became useful. Was trying not to over-add stuff.
I’m going to work on readmes, documentation, website, templates, and external demos…get it all consistent with 2.0
anything else you need @wilkerlucio?
I think that's all for now, thanks for looking it up 🙂
I'm going to try hooking all then up
do you think are going to do that rebase soon? just for the
integrate-ident!, but I can live for a while with my own copy of it (for the
also merged Om Next history for the files I imported (checked with David first…he was cool with it)…so, any contributors for Om next now get credit here too
looks like I lost a little history when David renamed files back in 2015, so not all of his commits came in 😕
that's ok, ins't like you are hiding it came from there, quite the oposite
sure…David’s been on board from the beginning (I thought about a fork back in 2015) and it is well-documented. Just sad to lose the history.
took me hours to manipulate git tree filtering and rebasing to make it look as seamless as it looks
@tony.kay where can I read more about the new stuff related to load markers?
here’s how it works now: You can use a keyword for the marker option
:marker :x and the load marker gets normalized into a table…query for your marker using a join on the ident.
0.2.0-SNAPSHOT is on Clojars adapted with then new names for send