I’ve created a PR to update semantic-ui-wrapper to semantic-ui-react 0.82.0 and change the generators to accommodate that https://github.com/fulcrologic/semantic-ui-wrapper/pull/5

@liesbeth Released as 2.0.1

I've just upgraded to 2.6.0-RC5-SNAPSHOT from 2.5.8. But now I am getting Uncaught Error: No protocol method IAssociative.-assoc defined for type cljs.core/Atom: [object Object]

Ah I thought I didn't have a stacktrace from my code but I do, let me see if I can figure it out

Seems merge-component! changed:

(prim/merge-component!
                         (:reconciler app)
                         UiGuide {:ui-guide/lesson lesson
                                  :db/id 1
                                  :ui/step 0} :replace [:root/guide])

I updated because a set-state! seemed to not trigger a re-render and I remember seeing an update about doing lifecycle methods properly, and it seems in 2.6.0-SNAPSHOT the set-state! no longer updates within the callback that does the set-state!. Trying later versions until I hit the assoc bug again.

@bbss Thanks for the report…we just did a refactor to deprecate certain names, but that should not have broken anything

Okay, still looking into the different versions. I'll keep you posted.

on set-state: It is a direct call through to React now, so it should work as documented by React

what do you mean “no longer updates within the callback”?

The callback part is not important I guess. But it used to be that in the clickhandler I could set-state! and then get-state and the get-state was updated to reflect the set-state!

I just updated the SNAPSHOT with a fix, try that again for the mege component bug

Will do.

Ah, so you’re saying that setState isn’t “immediate”. That is true for React 16+

it is a queued thing, in prep for async rendering.

okay, and react 16 is since version 2.6?

If you set your React version explicitly to an older version, that might return

React 16 will be the default for 2.6, yes, but 15 should still work

had to remove fulcro from cache, my app now renders with 2.6.0-RC5-SNAPSHOT, but differently.

I'm using react portals, hope that's not affected.

I guess I was already using react 16 as portals are a react 16 feature.

Hmm, something strange happening. Initial page load renders the app, but then after live-reload I get a

Uncaught Error: Assert failed: (component? component)

In my reload remount If I increase the timeout from 1ms to 1000ms it renders again. (no more assert component? fail) I have a setTimeout on my reload re-mount because when I didn't do that I got a websocket error. However the render still does not render one of my components. Inspecting further.

The reason it renders differently is because the previously erroring merge-component! doesn't seem to work anymore.

hm… @currentoor it seems tests of merge-component! were insufficient.

you’re right, @bbss, my patch to merg-component wasn’t right

just a min

sure thing, thanks for being helpful as ever

I put things in SNAPSHOT that have not been well-tested…so this time that proved to be a good idea 🙂

I updated it…try again

BTW, what websocket error?

there was a problem with websockets not waiting for establishment, but that should have been fixed a few versions ago

in 2.5.8

I’m actively using websockets in a project, and that fix works for me

@bbss good catch

🙂

@tony.kay weird, i tested that line’s change in my app, which certainly relies on fulcro calling merge-component and it didn’t throw

Trying again. The websocket error started happening around the time of that update (I think I know which one you are referring to, I reported the issue with load in started-callback not working on slowish ws connections).

there is a warning that it is waiting, but that is what you want

@currentoor it is the ! version…you didn’t swap on state

so it was just getting an atom instead of state, and doing nothing

@tony.kay i understand that, i’m just surprised that my app worked despite that bug

I don’t see how it could have

oh…used the new version?

Oh yes, I get that sometimes when my app errors, I think that fix actually did work. But I am back in Europe nowadays, which is where the "slow" server connection comes from so haven't been able to verify from Korea where I usually live.

@currentoor would have only showed with integrate ident portion

ok, @bbss, so you’re going again?

yes, in a month or so I'll go back. Fairly certain that it did solve the issue I was having though.

maybe __integrate-ident-impl__ should also have a :pre check to verify it’s an atom?

it should not be an atom

Yes, new version merge-component! works again. Cheers!

sorry that’s what i meant, verify it’s a map

the wrapper function has that check i think

unfortunately, atoms are record which say true for map?

I think

oh…

it’s an internal implementation detail, so I’m less worried about that, and more worried that there is no automated test covering merge-component!

yeah that would be nice 😅

those are harder to write, since it uses a reconciler

well, with when-mocking they are tractable

but more fragile

still having the issue with the setState though. Any reading-up I should do about the immediate/async rendering?

re-render of components' this I set-state doesn't happen.

that was kind of word salad

hahaha I was reading it back and thinking... Hmm it makes sense in some way..

Let me rephrase..

https://reactjs.org/docs/react-component.html#setstate

“Think of setState() as a request rather than an immediate command to update the component. For better perceived performance, React may delay it, and then update several components in a single pass. React does not guarantee that the state changes are applied immediately.”

Okay, that explains why the print of get-state right after is not reflected.

I set-state on the this of a component. But that component doesn't re-render after said set-state.

I think it's the componentShouldUpdate. But my react knowledge is not awesome.

my guess is you’re messing up…either you’re not changing the state to something new

or you’re mis-measuring re-render

shouldComponentUpdate is set by Fulcro

and it has been changed recently due to the changes…there could be a bug

let me glance at it

it looks right to me…it says “yes” if props, state, or children changed

and I’ve done set-state in my own demo code and it updated

NOTE: There is a callback parameter to set-state that will be called after the state change is applied

I'll check that callback too

The set-state! callback gets called, and the state is updated and changed when I call get-state in that callback.

But no re-render triggered on the component who's this I passed to the set-state! call.

I’m compiling the book demos with Rc5

My fear is it is something to do with the react portal.

possible I guess

so, I’ve got some regressions on the book demos…some of the old libs I was demoing don’t work with newer react

I notice something kind of strange. After I run the callback with the problematic set-state!. I get

[679.214s] [fulcro.client.primitives] integrate-ident is deprecated and will be removed in the future. Please use fulcro.client.mutations/integrate-ident* in your mutations instead.

200-1500ms difference between the logs

pressing a different button does trigger a re-render that does reflect the state from the problematic set-state!.

the warning was just added. We’re moving that function, since it is more of a mutation helper

are you calling it that much?

Possibly, not sure where I call it. I'm "replaying" edits to a codemirror instance. I think it's from there.

Ah, no I think it's from elsewhere, one of my push-handlers.

I’m a little stumped, and it turns out I’ve got some regressions in the book demos, so I should fix those first…some of them are old versions of demo stuff that requires react 15.

I'm also a little stumped but I'm sure I'll find a way (hacky) to make it work. Tried .forceUpdate on the this. But that doesn't seem to do it. So it's probably not the shouldComponentUpdate then.

yeah, forceUpdate bypasses that

I think I got it.. And it ended up to be what you said: "you’re messing up" measured the wrong re-render.

Ugh, I should get to bed. 😄