Fix on #35679

[louismaximepiton]

Re-open from #36585 (Sorry couldn't re-open on the other one) trying to fix #35679 discussions.

This PR tries to fix the #35679 (comment).

[GeoSot]

thank you @louismaximepiton for your consistency and for opening again the PR.

May I ask one question? The change on line 347 & 448 depends on the other two?

Why, I am asking:

bootstrap/js/src/tooltip.js

Lines 376 to 378 in c1813ef

	_getTitle() {
	return this._resolvePossibleFunction(this._config.title) || this._config.originalTitle
	}

_getTitle is used to resolve this duplication, and in advance, it uses the _resolvePossibleFunction to resolve possible given function. And of course function is not null but maybe returns an empty string or null

So maybe we can initialize title & content in the end of _configAfterMerge(config) {
after the checks and check after the initialized properties? ?

bootstrap/js/src/tooltip.js

Lines 600 to 605 in c1813ef

	if (typeof config.content === 'number') {
	config.content = config.content.toString()
	}
	return config
	}

[louismaximepiton]

thank you @louismaximepiton for your consistency and for opening again the PR.

Sorry to re-open with so much delay 😖

May I ask one question? The change on line 347 & 448 depends on the other two?

No, it's an independent change for me. This is done to reduce the bundle but I might be wrong. The 2 same lines are called in show() and I couldn't spot any use of this.tip between the actual removal and the removal in show(). So this way, this.tip is still removed but if it is there for the comprehension of the code it might be kept here,

Why, I am asking:

bootstrap/js/src/tooltip.js

Lines 376 to 378 in c1813ef

	_getTitle() {
	return this._resolvePossibleFunction(this._config.title) || this._config.originalTitle
	}

_getTitle is used to resolve this duplication, and in advance, it uses the _resolvePossibleFunction to resolve possible given function. And of course function is not null but maybe returns an empty string or null

So maybe we can initialize title & content in the end of _configAfterMerge(config) { after the checks and check after the initialized properties? ?

I think I might have missed something here. You wanna try something like: config.title = this._getTitle() (or equivalent) to run the function only once per tip declaration and remove the other calls to getTitle?
So the function would be run once, put its result and we only need to check for existence? I have few more questions:

• Do we need to change the _getContentForTemplate() function ?
• Since it will be called with _getConfig() only, that is itself called by the constructor only, if the function send a dynamic result, would it be overridden by each time it recreates ?

---

Thinking about that, I don't know if this was your idea, but if with actual _isWithContent() implementation, we do something like:

this._config.title = this._getTitle()
if (!(this._isWithContent() && this._isEnabled)) { // l.197
  return
}

Then we might need to change _getContentForTemplate() to use this._config.title instead of this._getTitle(). I'll give it a try in the next commit to see if it could work.

[GeoSot]

Do we need to change the _getContentForTemplate() function ?

Probably not

---

Since it will be called with _getConfig() only, that is itself called by the constructor only, if the function send a dynamic result, would it be overridden by each time it recreates ?

And now we are getting closer to the real problem:
Options:

1. resolve possible dynamic results on the constructor (getConfig)
   • pros : calls to dynamic calls are done only once, save calculation time
   • cons : possible dynamic calls are not updated
2. resolve possible dynamic results every time we need them(getConfig)
   - pros : possible dynamic calls are always updated
   - cons : calls to dynamic calls are done and checked every time

So in each case you are facing a different issue, where NOBODY can be pleased . The question here is what is the best of the two available solutions.
I had picked the first, not knowing that there ware cases, devs made changes and wanted the tooltip to be updated automatically

After an issue, I was forced to return to the second option. But if we do not resolve in each check our possibly dynamic calls we will be never sure about their real result

[louismaximepiton]

So in each case you are facing a different issue, where NOBODY can be pleased . The question here is what is the best of the two available solutions. I had picked the first, not knowing that there ware cases, devs made changes and wanted the tooltip to be updated automatically

After an issue, I was forced to return to the second option. But if we do not resolve in each check our possibly dynamic calls we will be never sure about their real result

It took a long time for me but I think I finally get to your point (I guess 😅) I wonder if it exists a simple solution like: compute title once per rebuild, store the value and use it where it's needed in order to not compute the potential functions several times (as it is done in main). From what I've seen, it would introduce more complexity to the component and maybe increase bundle size. Do you want me to give a last try for a working sample on what I've in mind? Or should it be kept for v5.3.0+?

[GeoSot]

It wouldn't introduce more complexity, but we would fallback to the previous version, with a cached value (just the case I 'solved' in the previous PR). 😔
So for now I suggest just try the one change u proposed on 'setContent' and not something more . (After the release of course you may try any improvement 😉)