#bookbrainz

CatQuest: did you face the slow keystroke response on modal or on whole unified form?

whole unified form, but it was magnitudes worse in the popup(modal?)

apart from modal(popup?) thing other components of uf should work fairly smooth, it would be helpful if you can provide me which specific field's performance is worse as compare to entity editor?

in the whole form they are all bad, in the mpopdal it was worst in.. typing the annotation

iirc

all typing in the popmodal was excruciating

in the whole form they are equally as bad i mean

except edit note it was the least bad

so like annotation in uf is slower than annotation in entity editor?

I just update the new-creation-form branch from master, and pushed the uf-editor PR again on test.bb

CatQuest: Can you see if the typing aspect is any faster now?

monkey: do you also think it would be a good idea to have separate row for each work in content tab(like identifier editor)?

Yes! I actually just a minute ago wrote that sentence in the comments I'm compiling :)

Here it is:

> I agree the works should be each on a separate row instead of a multi-select.

One added advantage: in the future we will most likely have a way to specify what page a certain work starts at, and it will be much easier if each is in a separate row.

It would also be helpful if we want to show a bit more information for each work in that tab like author (+ checkbox to copy author rel from AC).

Yep, also one more thing slow performance on modal might be cause of uf and modal sharing the same root state i.e state update on modal also cause useless update (or render) on form as well.

I figured it would be something like that. How do we prevent that from happening?

something like freezing form when modal is open?

The issue is that the redux actions that are dispatched affect more than one part of the state?

i.e. they will cause a state change in the modal state as expected, but other parts of the form are also reacting to the same actions?

not state but more than one component dependent on that state

OK. So more a question of rendering on state change (i.e. a React problem, not a Redux problem), correct?

hmm something like that

didn't realize it would be noticeable though, i think it is mainly due to large language dropdown which get render 2-3 times on modal which make this worse

That was why I updated test.bb this morning, hoping it will make it more usable

but this shouldn't be an issue after async language select, i hope

Speaking of, let me work on that one and see if we can get it merged, then I'll try to update new-creation-from branch and deploy the PR again.

monkey: yes i can. pls link me directly to the creation form again pls

But I don't think it will be much improved.

We need another bit of time to figure it out, will ask you again when we think it's improved

sure!

I also have to say this yet again: over engenering "states" and "freezing" and the like is in my humble opinion not the way to go about it. instead doing a round to "de-complexify" code. especially ui/ux code to mak it "dumb" instead of "smart" and instead do "smart" things *after* a person clicks a button or selects or the like. is the right way. look how mb does it. searching and typing has never been an issue there.

art of this is elasticsearch I'm sure, we really should switch to solrs soon

like an annotation or a review note shoudl jsut be plain old hml text-fields

No, not at all related to the search itself

what are "states" exactly?

why do we need them?

what do they do?

The whole state thing is basically where we store the content of each field in a structured manner, that is then sent to the server as a form

...

and if we *don't* have that?

If we don't have that we need to rewrite the entire entity editor :)

well...

that's what this shoud e. (in my *humble humble* opinion)

what we call state = backbone in the old MB

hm

Same same

But different

it shoudl be same same

not different

well

what does mb do? it doesnt have these "states" i think?

Yes it does

what does it do differently thna bb?

Perhaps not exactly the same tool, but *some* tool

that tool seems ot be a hella lot less laggy. tbh

Well, most of the issue is some implementation we don't do correctly, and that's fixable

hm

it's literally always been a little slow though. like years and years ago. the initiall opening of an entity add/edit page has always taken extra tiem to load

Probably the very same implementation problem that's been there all along…

and it means i have to wait before editing like the title or whatever because until the page finishes loading it wont register any imput. and so if i type the title before tht and thne press "guess2 it wont work, evne if i do it after it finishes loading

exactly

btw. we should have a "guess case" type button on title too

all titles, names and so on

you can copy the logic direct from mb too. just have two states for now. english and sentence

later french/german/whatever can also be muxed in

Shubh: Overall I think the unified form is going very well. Still a few teething issues but nothing that seems unsurmountable.

Some more detailed review here: https://gist.github.com/MonkeyDo/9210c1da73b64a...

On a separate note Shubh: reading this line, is the MAX_F2_OPTIONS also used as a general max amount of items to show in the dropdown? https://github.com/metabrainz/bookbrainz-site/p...

monkey: Yep, random though

OK. As I commented I don't think we should restrict the number of frequently used languages (there are only 21 in the DB) but I can rename and reuse the variable as a max number of items shown. Will make that change now

(if you don't mind)

sound good to me :)

monkey: while working on the client side with live reload enabled, sometimes I observe that the css is not getting updated when refreshed. So I have to restart the server. Are there any changes that might help?

The css file name doesn't change, so it might be cached by the browser. I usually have my browser console open with the option selected to "Disable cache": https://usercontent.irccloud-cdn.com/file/4RdDk...

This is in the browser console settings

Is there any caching done by webpack?

At some level yes

Because hard reloading also does not help in those cases.

Ah, interesting.

You could possibly add a content hash to the filename here: https://github.com/metabrainz/bookbrainz-site/b...

Okay, I'll try it and let you know if I still face that issue

You can check the webpack logs to see if the file is emitted (= written to disk)

If all else fails you can run `npm run build-scss`in the docker container

ok

Also for displaying the reviews, which would look better, showing review like cards (https://critiquebrainz.org/review/) or as tables (https://critiquebrainz.org/release-group/be5826...) ?

Cards certainly at least for the entity page

If we were to have a specific page to show all reviews for an entity ("show all" link sort of thing), conceivably tables might work, but then we're just duplicating critiquebrainz, we might as well directly link to the CB page

I have almost reached something similar to what I proposed and the cb website, I'll show it to you tomorrow.

Nice !

monkey: is there any known way to append icon at accordion header in bootstrap v4?, i've added one in details tab accordion (https://test.bookbrainz.org/create) but its kinda clunky :(

Nothing I know off the top of my head. Maybe this? https://react-bootstrap-v4.netlify.app/componen...

Although I'm not opposed to the CSS solution :)

for some reason, css solution is slow on transition maybe due to late addition of `.show` class? but not sure any idea?

Yes, that's what I'm guessing too.

tbh without icon accordion doesn't look like an accordion

Agreed

good thing, they improve this in v5

I tried adding the transition to the class `collapsing`which is added during the accordion toggle transition, seems to work well:

`div[class~=collapsing]+div[class=card-header] .accordion-arrow`

To be clear, in addition to, not replacing styles for `show`

Hm, it reverses the delay (delay after closing, not after opening) which looks a lot better (reactive?) IMO, but maybe that's not what you're looking for

this looks smooth, what do you think? https://www.irccloud.com/pastebin/LX5cQy6N/

I looks a bit choppy for me

hmm, is there way to make this fast but also smooth?

Not that I can think of with css, but I think this works OK:

Changed the transition speed a bit

CatQuest: I put the new language-select-that-works-more-like-MB on beta.BB

Could you please have a look and let me know if it feels any faster?

looking good, lets go with this then :)

[18:02] <monkey> If we were to have a specific page to show all reviews I epect ti to wrok like mb: on the edition-group page, reviews for the edition group will show (i'd do as the mb one, right now i actually don't know if it only will show the first one, the higest rated one or any review an RG has randonly)

monkey: yes i will test!

ok so this is what i'm noticing: typing is much, much faster. but things like selecting after search, language search or entity search (for autor credits etc) as wel las any btutton push, (guess case, add a new author credit, etc) is so. hella. slow

typing in isbn is really slow

name was fast

wow selecting "create new work" after searching and not finding anything takes up so much energy my music player crashed (not kidding)

the add work modal is as slow as ever. if anything worse

trying ot work in it is hanging my system pretty hard

Ah, test hasn't changed, I was asking to test beta :)

ಠ_ಠ

sorry

no worries

give me a link to the thing on beta then. i'm ultra lazy and should go and make dinner but i cna test things just before that for sure

you got mad about the ultralazy

anyway let me see

monkey: you should put things on test before beta you know... if things on beta contradict new fixes, then perhaps we need *another* test server. gsoc.bookbrainz.org? whatever

anyway the language selection now is... snappy! :o in comparason

well done

anyway i cna finally add quite a few books that's been waiting. so i thank you a lot for this