New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Manually setting the busy prop in b-table seems to be broken #1398

Closed
robcresswell opened this Issue Nov 23, 2017 · 5 comments

Comments

Projects
None yet
2 participants
@robcresswell
Contributor

robcresswell commented Nov 23, 2017

Simple JSFiddle showing that toggling the busy state between true and false leaves the table in its busy state (with faded styling etc).

JSFiddle: https://jsfiddle.net/8qx0syev/8/

Checked in Firefox Beta (58) and Chrome Beta (63)

@tmorehouse

This comment has been minimized.

Member

tmorehouse commented Nov 23, 2017

I've made a change to your fiddle, and set the default busy state to false, and don't see the issue (I switched to dark table to see the difference easier). https://jsfiddle.net/8qx0syev/10/

So it looks like the busy state is slightly foobarred only if it is initially true on mounted.

@robcresswell

This comment has been minimized.

Contributor

robcresswell commented Nov 23, 2017

Interesting observation! In my downstream code I call the load() function during the created() hook, which immediately sets loading to true and gives me the frozen table as above, even if data initally defined it as false. Thanks for confirming.

@tmorehouse

This comment has been minimized.

Member

tmorehouse commented Nov 23, 2017

I think we need to add an additional watcher to monitor the busy prop.

@tmorehouse

This comment has been minimized.

Member

tmorehouse commented Nov 23, 2017

Actually nope... we don't need a new watcher. we just need to not populate 'localBusywith this.busyon mount/create, aslocalBusy is used internally only by provider functions.

Should be a quick fix.

tmorehouse added a commit that referenced this issue Nov 23, 2017

tmorehouse added a commit that referenced this issue Nov 24, 2017

@tmorehouse

This comment has been minimized.

Member

tmorehouse commented Nov 29, 2017

v1.3.0 has been release, and the issue should be fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment