-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
don't override document.title if set to None #1343
Conversation
This allows users to override `document.title` during runtime with a clientside callback or a special component (plotly/dash-core-components#833)
update_title, | ||
}; | ||
} | ||
|
||
UNSAFE_componentWillReceiveProps(props) { | ||
if (this.state.update_title && props.isLoading) { | ||
document.title = this.state.update_title; | ||
} else { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While this allows the clientside callback to set the value, it seems to break existing tests / behavior. Would a better verification be to only revert back to inititalTitle
if the value is equal to update_title
instead? Possibly the same chekc for update_title
- only update if the value is currently initialTitle
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! I totally misinterpreted what update_title
meant. I believe e190cc9 is the logic we're looking for
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it'd be safer to bail out entirely (before even the props.isLoading
test) if !update_title
. Then this entire component would be a noop, as it should be in that case; callbacks can do whatever they want with document.title
and we won't interfere.
When you do have an update_title
, I may agree with @Marc-Andre-Rivet that there needs to be a test when we're reverting back to the non-updating title. Consider a callback chain, where the first callback changes document.title
, but we're still in a loading state so DocumentTitle
doesn't receive new props and we don't pick up the changed title into this.state
. Then after the second callback we reset document.title
to this.state.title
, losing the callback-provided title.
Seems to me the logic you have right now is fine during loading, but when reverting to this.state.title
below it would be better to do something like:
if (document.title === this.state.update_title) {
document.title = this.state.title;
} else {
this.setState({title: document.title});
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @alexcjohnson @Marc-Andre-Rivet ! I believe I have addressed your comments and added the appropriate tests now.
Tangentially related to this PR - you can set |
weird, perhaps we somehow got update: yes, somehow we have isort@5.1.0
|
I added this as well and kept the |
@@ -725,7 +739,9 @@ def index(self, *args, **kwargs): # pylint: disable=unused-argument | |||
config = self._generate_config_html() | |||
metas = self._generate_meta_html() | |||
renderer = self._generate_renderer() | |||
title = getattr(self, "title", "Dash") | |||
|
|||
# use self.title instead of app.config.title for backwards compatibility |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In principle we could make title into a @property
that syncs app.title
with app.config.title
- but not a big deal. Most people should just use the kwarg regardless.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! 💃
Dunno what the deal is with the "reintroduced" percy snapshots - but I'd just ignore it this time and look into it if we see that again. |
Isn't below simpler? def interpolate_index(self, **kwargs):
kwargs['title'] = 'Custom Title'
return dash.Dash.interpolate_index(self, **kwargs)
app.interpolate_index = interpolate_index.__get__(app) |
I'm not sure what you mean @OverLordGoldDragon - simpler than |
@alexcjohnson Surely not, but your code blob isn't shown in this PR nor in Releases (it was unclear where the " |
OIC - yeah, this PR expanded a bunch from its original purpose, so we never showed the simple examples - sorry for the confusion. We've documented the new behavior at https://dash.plotly.com/external-resources (though @chriddyp it feels to me a bit hidden on that page - maybe time for a dedicated |
Edit: This feature is now documented in http://dash.plotly.com/external-resources. Look for the
title=
andupdate_title=
. See the "Customizing Dash's Document or Browser Tab Title", " Update the Document Title Dynamically based off of the URL or Tab", and "Customizing or Removing Dash's "Updating..." Message" sections.As requested by a Dash Enterprise customer.
This allows users to override
document.title
during runtime with aclientside callback or a special component
(plotly/dash-core-components#833)
Example of modifying during runtime:
Example with custom table title via index string:
This is a follow up of #1315.