Skip to content
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

[Tab] Cached content is added back on each open (losing changes) #2534

Closed
andreyvk opened this issue Jul 7, 2015 · 26 comments
Closed

[Tab] Cached content is added back on each open (losing changes) #2534

andreyvk opened this issue Jul 7, 2015 · 26 comments

Comments

@andreyvk
Copy link

andreyvk commented Jul 7, 2015

Hi,

I've just upgraded to Semantic 2.0.0. Great job on this one! Thanks @jlukic

I have dynamically opened tabs in my app, contents of which are AJAXed by semantic and normally include HTML and <script> tags. On the first load of any tab everything seems to execute well and work well too, however if tab is clicked on again or focused back on, all the dynamically generated elements are lost (i.e. as if html content is re-inserted but javascript never fires).

Here's a fiddle

Question: It might be a correct behavior in some cases, but how can I make tabs evaluate the content trully once, so that when user goes back to a tab, everything remains as it was? For that matter evaluateScripts: true wouldn't work for me either.

PS: the Tab/Settings documentation lists a parseScripts parameter. Shouldn't it be evaluateScripts instead?

@jlukic jlukic added this to the 2.0.2 milestone Jul 7, 2015
@jlukic
Copy link
Member

jlukic commented Jul 7, 2015

Docs list the wrong name for the setting, it should be evaluateScripts

@jlukic jlukic modified the milestones: 2.1, 2.0.2 Jul 7, 2015
@jlukic
Copy link
Member

jlukic commented Jul 7, 2015

Basically response is cached before parseScripts runs. Which means when tab is revisited it will not run scripts again and will not use the result of first script evaluation. This is a bug with once. Setting cache: false will probably fix this for now.

The actual fix will have to be more involved. I've marked this for a later release.

@jlukic jlukic changed the title [Tab] evaluateScripts: 'once' introduces undesired behavior [Tab] Cached content is added back on each open (losing changes) Aug 11, 2015
@jlukic jlukic modified the milestones: 2.2, 2.1 Aug 12, 2015
jlukic added a commit that referenced this issue May 15, 2016
…inal response so that execution occurs in same way each load. HTML caches final html content after callbacks
jlukic added a commit that referenced this issue May 15, 2016
jlukic added a commit that referenced this issue May 15, 2016
@jlukic
Copy link
Member

jlukic commented May 15, 2016

I've added a new setting cacheType which can have two settings response or html (defaults to html).

Response will cache the original response so that it can be played back identically on future callbacks (current behavior), html will cache the html resulting from script evaluation and callbacks.

You will have to now call with cacheType: 'html' to see the chances in 2.2 This is to preserve functionality for users who were relying on tab functioning as it has before.

jlukic added a commit that referenced this issue May 15, 2016
@jlukic
Copy link
Member

jlukic commented May 15, 2016

@andreyvk I'm really sorry how long it took me to address this.

Fiddle example from 2.2
http://jsfiddle.net/arpb4o24/

@jlukic jlukic closed this as completed May 15, 2016
@andreyvk
Copy link
Author

andreyvk commented May 16, 2016

@jlukic Thanks. I've tested on a fiddle, but i think we still have the same issue. Here's fiddle: http://jsfiddle.net/andreyvk/zjqxxmoj/

Maybe I cant get configuration right? The idea is very simple:

  1. When tab is focused on, content loads and JS executes, initializing the DOM (if content is already on the page, then JS just ran for the first time)
  2. Upon a second focus/click on the same tab, content must not reload nad JS must not run again (i.e. tab is cached and scripts are evaluated once. No replay needed). Just leave the tab be, cause it was already initialized before.

@jlukic jlukic reopened this Jun 13, 2016
@jlukic jlukic modified the milestones: 2.2, 2.2.1 Jun 26, 2016
@jlukic jlukic modified the milestones: 2.2.3, 2.2.4 Aug 22, 2016
@usef911
Copy link

usef911 commented Aug 30, 2016

Hi @jlukic
Thanks for all the hard work. I've been watching this issue for a long time hoping for a resolution soon. Is there anything I can do/contribute to push this higher in your priority list?

Thanks

@andreyvk
Copy link
Author

Hi @jlukic,

We would like to sponsor this fix so you could roll it out. We are getting a lot of complains regarding our product primarily because we are not being able to make some tabs load only once and then remain unchanged afterwards. Do you think you can find some time to look into this asap?

@jlukic
Copy link
Member

jlukic commented Oct 23, 2016

Yeah @andreyvk if this is important to you I can put a fix in this week. If you want to reach out by gchat feel free to hit me up at [email protected], but I think I have a clear test case. I've just been slowed down lately by increasing personal / work obligations.

@andreyvk
Copy link
Author

@jlukic , unfortunately this is very important at the moment. I've been waiting for this fix like a kid is waiting for Christmas. It's actually becoming a huge inconvenience for our clients.

Just as a reminder on this issue:

  1. Some tabs need to be loaded once and only once (i.e. no re-loading/re-initializing on further tab selection)
  2. While that tab is loaded once, JS scripts must also be executed once, so tab state isnt lost at all.

Thanks for your email address (!), but I wont be bothering you there. I just sincerely hope you can find time to fix this one :)

@ivantcholakov
Copy link

Meanwhile you can try delegation:

$('body').on('click', 'button', function() { alert(1) });

@usef911
Copy link

usef911 commented Oct 24, 2016

Hi @jlukic
I second @andreyvk , adding this feature will really relieve a lot of grief for our project, it's really a very important feature we've been waiting for for a long time. Appreciate the help and hope you can squeeze this in to your schedule this week. Looking forward to the update 👍

@jlukic
Copy link
Member

jlukic commented Oct 25, 2016

@andreyvk

I think using cacheType: 'response' and evaluateScripts: true together should do what you're expecting (alerts appears everytime, append appears only once).

If this isnt correct, please let me know the expected response, so I can consider changes to the component.

http://jsfiddle.net/7k8nyqb2/

@andreyvk
Copy link
Author

@jlukic

If you click on the "First" tab more than once you would notice that time (in ms) is changing. Which means that JS is fired again and again every time tab is selected. This isn't the correct/desired behavior. Tab must be loaded and JS "ready" fired only once.

Thanks for this! Really )

@jlukic
Copy link
Member

jlukic commented Oct 25, 2016

I see what you mean, I'll add something tomorrow later this week

jlukic added a commit that referenced this issue Oct 28, 2016
@jlukic
Copy link
Member

jlukic commented Oct 28, 2016

Hey @andreyvk thanks for your patience.

I've added a new cache type dom which caches a cloned DOM fragment, which is re-used on each tab reload.

This should have the effect you're looking for

Example:
http://jsfiddle.net/tuhq4boc/

@jlukic jlukic closed this as completed Oct 28, 2016
@andreyvk
Copy link
Author

@jlukic

Thanks for the hard work! But im sorry to say, that the fix that you provided did not work though...

I found that all <script> tags are removed from the tab content, when tab is clicked the second time around. This kills all the objects there were created on the first place (in other words, we have <script> tags on tab content and some of them contain code that initializes internals of our tabs). I looked at the tab.js code. Seem like this piece of code on line 480 is the reason (of course you know it 😄 ):

setTimeout(function() {
    var
        $clone = $tab.children().clone(true)
                      ;
        $clone = $clone.not('script');
         . . .

Sorry for misunderstanding. I should've told you before, but I had no idea that you'd be taking this approach in tackling the issue.

May I ask why you always need to clone/re-insert html, when tab is clicked on? Technically what's needed is to only make tab content visible, because it was hidden on the first place.

@usef911
Copy link

usef911 commented Nov 1, 2016

Hi @jlukic
Any updates? Appreciate the hard work very much.
Thanks

jlukic added a commit that referenced this issue Dec 29, 2016
@jlukic
Copy link
Member

jlukic commented Dec 29, 2016 via email

@jlukic jlukic reopened this Dec 29, 2016
@jlukic jlukic closed this as completed Dec 29, 2016
@jlukic jlukic modified the milestones: 2.2.8, 2.2.5 Dec 29, 2016
@andreyvk
Copy link
Author

andreyvk commented Jan 1, 2017

@jlukic that actually looks great! thanks a lot and happy NY! Btw, any idea when can we expect 2.2.8 release?

@andreyvk
Copy link
Author

andreyvk commented Feb 2, 2017

@jlukic How are you? Any updates on the next bug fix release?

ali1k added a commit to slidewiki/custom-semantic-ui that referenced this issue Feb 14, 2017
* 'master' of https://github.com/Semantic-Org/Semantic-UI: (24 commits)
  Fix build scripts to work again
  Date
  Fix autoinstall breaks when param used after git clone of repo (no package manager)
  Builds 2.2.7
  Update versions
  Build 2.2.6
  Hotfix for typo
  Fixes let usage
  Update RELEASE-NOTES.md
  Build 2.2.5
  Add missing checkbox var
  Build dist
  Adds missing checkbox variables
  Semantic-Org#2534 release notes
  Semantic-Org#2534 - adds new DOM caching, which preserves events and final rendered state
  Add CDNJS version badge in README.md
  Update checkbox.less
  Fix bug in search related to DOM fragment removed from document
  Adds container option for sticky, adds checkbox vars
  Transition can now read final display state from metadata
  ...
@andreyvk
Copy link
Author

@Banandrew hi. Do you have any idea of when the next release is gonna be? Or at least where I could monitor that info? Our app heavily relies on SUI and some enhancements (like this one) are crucial to us. We are really looking forward for this enhancement.

@awgv
Copy link
Member

awgv commented Feb 20, 2017

Hi @andreyvk, Jack’s currently splitting his time between NY & SF working with a SUI company, and will return working on SUI development full-time sometime in the near future, but exactly when is unknown . My advice to you, is to see if you can implement the commit above in your SUI copy until 2.2.8 arrives.

Sorry, I wish I could give you a better answer.

@andreyvk
Copy link
Author

@Banandrew, I was there when he left for work )) Pity that it takes so long though... SUI is crazy important to us.

In any case, i guess that I'd have to try and do manual merge like you suggested. Cheers!

@jlukic
Copy link
Member

jlukic commented Feb 21, 2017

Hey @andreyvk I'm going to release this later tonight. I know it's been annoying to wait.

@andreyvk
Copy link
Author

@jlukic that's great news! Really looking forward to that!

@falco467
Copy link

falco467 commented Mar 8, 2017

I still don't understand cacheType='html' or its is broken when using apiSettings. I'm using semantic-ui 2.2.9 and the tab is rebuild every-time (User Inputs and item-state is lost on tab change). I would think using cacheType='html' would load tabs only once from the server and then simply change the visibility of tabs without doing anything in the DOM.

I use the following workaround, which currently solves all my problems:

$(".tabular.menu .item").tab({
    history: true,
    onFirstLoad: function (path) {
        $(".ui.tab[data-tab='" + path + "']").load( path );
    }
}

The Content is loaded once and then just stays in the DOM. So User-Inputs stay when the tab is changed (because the other content is just hidden)

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

No branches or pull requests

6 participants