Fork me on GitHub
#fulcro
<
2017-12-03
>
tony.kay04:12:02

you looking at the 2.0 branches?

tony.kay04:12:14

oh, maybe I didn’t push

tony.kay04:12:37

hm…I don’t see that

tony.kay04:12:40

@wilkerlucio My bad…I just had not pushed those branches. The 2.0 versions of them on clojars were already right.

tony.kay04:12:06

Oh…and I had not pushed css to clojars…it is there now

tony.kay06:12:48

The develop branch of fulcro is now 2.0

tony.kay06:12:05

fulcro, fulcro-css, and fulcro-spec 2.0.0-beta1 on clojars

tony.kay07:12:12

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

wilkerlucio10:12:15

for people trying Fulcro 2.0, fulcro-inspect now is compatible with it, try the version 0.2.0-SNAPSHOT

wilkerlucio14:12:32

@tony.kay how can we focus a test on fulcro-spec? I can't find any examples on docs =/

tony.kay20:12:56

@wilkerlucio Put :focused after the string of a specification

tony.kay20:12:08

(specification "boo" :focused
   ...)

wilkerlucio20:12:28

thanks, I found reading the specs later, my bad, I stopped reading on the description and didn't found it right there

wilkerlucio20:12:42

but I think would be nice to have an example on the docs as well

tony.kay20:12:51

the spec docs should have it

wilkerlucio20:12:52

unless there is one, and I'm blind and didn't see it XD

wilkerlucio20:12:30

searching for :focus there, nothing found

wilkerlucio20:12:46

it says how to filter on the settings, but it's missing an example on specification

tony.kay20:12:58

so…you define them…but you’re right, there is no usage there 😕

tony.kay20:12:02

ok, need to fix that

tony.kay20:12:59

I’m excited about you doing that perf improvement 🙂

wilkerlucio20:12:17

and there still the serializable? one for us to look at 🙂

tony.kay20:12:28

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

tony.kay20:12:38

I’m game to just drop the check…

tony.kay20:12:12

it just means history could get hosed for support viewer…but I can consider that “your problem”.

tony.kay20:12:41

we can talk about it more in a bit. I was headed out the door…back in a bit

wilkerlucio20:12:44

but that was a different problem before

wilkerlucio20:12:54

the issue on the basis only started today when I moved to 2.0

wilkerlucio20:12:13

in the previous was something about the event cycle of the old om, probably something related to the forceUpdate

wilkerlucio20:12:55

ah, sorry, I misread you, yes, what you said is right 🙂

wilkerlucio20:12:33

and I agree it's the users problem if he starts throwing non-serialisable things there

wilkerlucio20:12:36

I was going to suggest we make the check optional, but I'm ok with just dropping it too

wilkerlucio20:12:24

I did a test dropping it here, man, the app is so fast now 🙂

wilkerlucio20:12:34

very responsive

wilkerlucio20:12:05

with all the optimisations the transact! went from 1 full second to 3ms

currentoor21:12:20

@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).

tony.kay22:12:39

@currentoor sounds fine to me. It is so easy to use with preloads

tony.kay22:12:20

@wilkerlucio Is your optimization of the basis-time well-tested against queries of the difficult kind? Recursive? Unions? with parameters? Etc.

tony.kay22:12:24

Oh I see…you used the AST. smart

wilkerlucio22:12:52

@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

tony.kay22:12:52

Using the AST covers a lot…like parameters

wilkerlucio22:12:05

yup, we can just ignore then 🙂

tony.kay22:12:20

ok, so, I’ve merged that

tony.kay22:12:28

I’m going to kill the serializable check

tony.kay22:12:14

there is a problem with that

tony.kay22:12:37

so, I store tx-result in the history, which is the return value of the mutation

tony.kay22:12:51

but most people don’t return a value, and just “accidentally” return random stuff

tony.kay22:12:26

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

tony.kay22:12:39

but it is too expensive the way it is

wilkerlucio22:12:42

well, you would have to return that from the mutation, did you see that happening often?

tony.kay22:12:09

“return” is just whatever you left on the last line…like a swap

wilkerlucio22:12:13

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

tony.kay22:12:23

yes, which is huge

tony.kay22:12:30

and confusing…but a different problem

tony.kay22:12:41

what if you did an AXAX request

wilkerlucio22:12:44

I was thinking on that, is a Fulcro concern to store history? maybe it should be delegated to tools

tony.kay22:12:45

or some other madness

tony.kay22:12:59

it is because of support viewer

tony.kay22:12:08

that is a first-class feature

tony.kay22:12:18

Now, I don’t have to store the tx or tx result, but it is useful data

wilkerlucio22:12:35

can't the support viewer itself be a tool? so it could store whatever it needs in response to events

tony.kay22:12:38

the tx is obvious, so I don’t mind removing the check for that…perhaps the answer is to NOT store the tx result

tony.kay22:12:21

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

tony.kay22:12:41

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

tony.kay22:12:56

I think dropping the tx result is the right thing

tony.kay22:12:01

and the serializable check from tx

wilkerlucio22:12:02

yeah, but sometimes (like my case) I just can't afford that, yet, hehe

wilkerlucio22:12:24

I'm ok with dropping those, or at least making it optional, because in my case it's an expensive thing

tony.kay22:12:56

agreed…when I wrote it I knew it was too expensive…so, I think this is the right course.

tony.kay22:12:34

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

tony.kay22:12:57

If defmutation had an explicit return value that defaulted to nil, it would not be an issue

tony.kay22:12:05

but that would be an API change

tony.kay22:12:09

so, building and testing…I’ll push beta2 in a few once I’m sure I didn’t make a typo or anything

wilkerlucio22:12:36

not sure if you read, fulcro-inspect is working on 2.0

wilkerlucio22:12:44

version 0.2.0-SNAPSHOT

tony.kay22:12:48

I did see that…great!

wilkerlucio22:12:33

I loved that the merges now come on tx-listen

wilkerlucio22:12:47

but I'm missing the :sends, you removed those intentionally?

tony.kay22:12:49

yeah, seeing the network results in history is nice

tony.kay22:12:04

did I??? …don’t remember

tony.kay22:12:19

oh. I think I did…why was that?

wilkerlucio22:12:20

I don't see then coming on the TX info anymore

wilkerlucio22:12:49

if we can get those back would be cool, unless you remember a good reason for removing then

tony.kay22:12:07

I’m looking through the git logs seeing if I made a note

tony.kay22:12:50

I think it was an accident

tony.kay22:12:20

so, they should be serializable…they are useful…yeah, don’t think I meant to remove them

tony.kay22:12:13

2.0.0-beta2 on clojars

tony.kay22:12:47

- include network sends in history - basis-time optimizations - serializable checks removed

tony.kay22:12:50

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.

tony.kay22:12:38

I’m going to work on readmes, documentation, website, templates, and external demos…get it all consistent with 2.0

tony.kay22:12:50

anything else you need @wilkerlucio?

wilkerlucio22:12:17

I think that's all for now, thanks for looking it up 🙂

wilkerlucio22:12:23

I'm going to try hooking all then up

wilkerlucio22:12:51

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 :set)

tony.kay22:12:57

it’s done

tony.kay22:12:08

did it last night

tony.kay22:12:39

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

tony.kay22:12:10

seems like it’s updated

tony.kay22:12:45

looks like I lost a little history when David renamed files back in 2015, so not all of his commits came in 😕

tony.kay22:12:04

but at least some of it is there.

wilkerlucio22:12:19

that's ok, ins't like you are hiding it came from there, quite the oposite

tony.kay22:12:27

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.

tony.kay22:12:05

but not sad enough to try to recover any more of it 😜

tony.kay22:12:25

took me hours to manipulate git tree filtering and rebasing to make it look as seamless as it looks

wilkerlucio23:12:14

@tony.kay where can I read more about the new stuff related to load markers?

tony.kay23:12:30

oh yeah…that would be good to document better 😜

tony.kay23:12:36

um….let me see

tony.kay23:12:24

hm…no where it seems

tony.kay23:12:01

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.

tony.kay23:12:27

I know I wrote a demo somewhere….but I’m not seeing it

tony.kay23:12:05

src/devguide/fulcro_devguide/H11_Server_Interactions_Network_Activity_Indicators.cljs:

tony.kay23:12:12

new devguide

wilkerlucio23:12:36

fulcro-inspect 0.2.0-SNAPSHOT is on Clojars adapted with then new names for send