tl;dr: The current approach for integrating Turbo with Flowbite is us

Hello <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-ur

Could this (resolve?) relate to <a class="issue-link js-issue-link" data-error-text="F

I don't think so. More at <a class="issue-link js-issue-link" data-error-text="Failed

Hey <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url=

Hello <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-ur

Hello <a class="user-mention notranslate" data-hovercard-type="user" data

Flowbite's handling of Turbo is using the wrong strategy about flowbite HOT 9 OPEN

daniel-rikowski commented on June 12, 2024 6

Flowbite's handling of Turbo is using the wrong strategy

from flowbite.

Comments (9)

daniel-rikowski commented on June 12, 2024 1

Hello @opedrosouza

it might be this problem, but considering the specific timing of the blinking in the screen recording, my first guess would be a "stale cache" or a preview problem. (i.e. the Turbo cache, not the browser cache)

You can test this quickly, by adding this to all pages, i.e. the layout file:

<head>
  ...
  <meta name="turbo-cache-control" content="no-cache">
</head>

If the problem is gone (and your site feels considerably slower 😢) then you can try to gradually reintroduce Turbo caching,
first by using no-preview instead of no-cache. If that works, then by only applying it to certain pages or by manually clearing the cache. (Both possible from JS) Also [data-turbo-temporary] may help in your specific case. For details see https://turbo.hotwired.dev/handbook/building#opting-out-of-caching

Perhaps in the future Flowbite can react to turbo:before-cache or [data-turbo-preview], perhaps even just by providing some documentation for typical use cases. (Modals via turbo-frame seems to be one of those.)

from flowbite.

Doddlin commented on June 12, 2024

Could this (resolve?) relate to #793 ?

from flowbite.

daniel-rikowski commented on June 12, 2024

I don't think so. More at #793 (comment)

from flowbite.

zoltanszogyenyi commented on June 12, 2024

Hey @daniel-rikowski,

Thanks a lot for the very informative issue and explanations!

I've recently merged a PR that should address this issue:

3f2ed0a

Can you please have a look at it whether it solves the turbo reload issue?

Otherwise, if you create a PR based on this I will review it and test it and merge it in case it will permanently resolve these turbo reload issues with Flowbite :) you'll get a spot as one of the contributors of Flowbite on the homepage too!

Cheers,
Zoltan

from flowbite.

opedrosouza commented on June 12, 2024

I don't know if my issue is related to this, but based on the context I think so.

Basically, I have a turbo_frame(id: :modal) on the body of my HTML, and all my CRUD operations are handled inside the modals.

When I open a modal on the route app/students then navigate to the route app/parents and go back to the app/students route the modal that I have opened before blinks on the screen.

Screen.Recording.2024-02-06.at.22.23.03.mov

here is a screen record of the behavior I'm facing.

from flowbite.

daniel-rikowski commented on June 12, 2024

Hello @zoltanszogyenyi, thank you for attending this!

Yes, I'm aware of #760, it filled the last gap on the "must reinitialize" side of Turbo, namely after changes caused by stream actions. (Also it enabled me to investigate the problem in the first place.)

But it does not solve the "must not reinitialize" side of Turbo, for parts of the page which must not be touched. Even though the approach is very elegant, it funnels even the most minor change of the page through undifferentiated, broad-brushed "reinitialize all the things" init-* handlers. (Imagine relevant meme here 😆)

Still, at the moment #760 only makes things better. ( ?)

I'm tempted to try a PR, although I find the step to delve into a new and foreign codebase to be daunting. Perhaps I'll try to create a small monkey patch first, to quickly aid people in determining if their specific Turbo-related problem is actually this problem.

from flowbite.

zoltanszogyenyi commented on June 12, 2024

Hello @ zoltanszogyenyi, thank you for attending this!

Yes, I'm aware of #760, it filled the last gap on the "must reinitialize" side of Turbo, namely after changes caused by stream actions. (Also it enabled me to investigate the problem in the first place.)

But it does not solve the "must not reinitialize" side of Turbo, for parts of the page which must not be touched. Even though the approach is very elegant, it funnels even the most minor change of the page through undifferentiated, broad-brushed "reinitialize all the things" init-* handlers. (Imagine relevant meme here 😆)

Still, at the moment #760 only makes things better. ( ?)

I'm tempted to try a PR, although I find the step to delve into a new and foreign codebase to be daunting. Perhaps I'll try to create a small monkey patch first, to quickly aid people in determining if their specific Turbo-related problem is actually this problem.

Thanks for getting back to me! I'll push the previous in the next release this week, I'm very open to collaborating and finding a permanent solution for the Turbo components - our codebase is relatively simple, in the sense that we have component classes for stuff like Accordions, Modals and there we have all methods and local variables.

One tricker part is the FlowbiteInstance manager, but you can find more info about it here: https://flowbite.com/docs/getting-started/javascript/

I'm also available to chit-chat on Discord!

Cheers,
Zoltan

from flowbite.

opedrosouza commented on June 12, 2024

Hello @opedrosouza

it might be this problem, but considering the specific timing of the blinking in the screen recording, my first guess would be a "stale cache" or a preview problem. (i.e. the Turbo cache, not the browser cache)

You can test this quickly, by adding this to all pages, i.e. the layout file:
<head>
  ...
  <meta name="turbo-cache-control" content="no-cache">
</head>
If the problem is gone (and your site feels considerably slower 😢) then you can try to gradually reintroduce Turbo caching, first by using no-preview instead of no-cache. If that works, then by only applying it to certain pages or by manually clearing the cache. (Both possible from JS) Also [data-turbo-temporary] may help in your specific case. For details see https://turbo.hotwired.dev/handbook/building#opting-out-of-caching

Perhaps in the future Flowbite can react to turbo:before-cache or [data-turbo-preview], perhaps even just by providing some documentation for typical use cases. (Modals via turbo-frame seems to be one of those.)

@daniel-rikowski it worked, but I think that this is not something truly related to cache itself.

I have a custom js controller which handle the modals on my app

the controller.js file here:

// controller.js
import { Controller } from "@hotwired/stimulus";
import { Modal } from "flowbite";

export default class extends Controller {
  constructor() {
    super(...arguments);
    this.modal = new Modal(this.element);
    this.destroyMissingBackDrop();
  }

  connect() {
    this.modal.show();
  }

  hide() {
    this.element.removeAttribute("src")
    this.modal.destroy();
  }

  // used for form submission as turbo:submit-end->modal--component#submitEnd
  submitEnd(e) {
    if (e.detail.success) {
      this.hide();
    }
  }

  destroyMissingBackDrop() {
    document.querySelector("[modal-backdrop]")?.remove();
  }

}

the HTML file here:

<%= tag.turbo_frame(id: :modal) do %>
  <div data-controller="modal--component" tabindex="-1" aria-hidden="true" class="fixed top-0 left-0 right-0 z-50 hidden w-full p-4 overflow-x-hidden overflow-y-auto md:inset-0 h-[calc(100%-1rem)] max-h-full">
    <div class="relative w-full max-w-md max-h-full">
      <!-- Modal content -->
      <div class="relative bg-white rounded-lg shadow dark:bg-gray-700">
        <button type="button" class="absolute top-3 right-2.5 text-gray-400 bg-transparent hover:bg-gray-200 hover:text-gray-900 rounded-lg text-sm w-8 h-8 ml-auto inline-flex justify-center items-center dark:hover:bg-gray-600 dark:hover:text-white" data-action="click->modal--component#hide">
          <svg class="w-3 h-3" aria-hidden="true" xmlns="http://www.w3.org/2000/svg" fill="none" viewBox="0 0 14 14">
            <path stroke="currentColor" stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="m1 1 6 6m0 0 6 6M7 7l6-6M7 7l-6 6"/>
          </svg>
          <span class="sr-only">Close modal</span>
        </button>
        <div class="px-6 py-6 lg:px-8">
          <h3 class="mb-4 text-xl font-medium text-gray-900 dark:text-white"><%= title %></h3>
          <%= body %>
        </div>
      </div>
    </div>
  </div>
<% end %>

I had to post the code to say that when the user clicks on the the button to close the modal it works perfectly, but when the user clicks on the backdrop or press Esc to close the modal it will behave like the video I posted here

I tried to find a solution to handle the click on the backdrop element on my js file but without success so far.

from flowbite.

secretpray commented on June 12, 2024

When I open a modal on the route app/students then navigate to the route app/parents and go back to the app/students route the modal that I have opened before blinks on the screen.

I had the same problem. I solved it this way

import { Controller } from "@hotwired/stimulus"

// Connects to data-controller="modals"
export default class extends Controller {
  static values = { 
    modalId: { type: String, default: "modal"},
  }

  initialize() {
    this.#addCacheControlMetaTag()
  }

  connect() {
    this.showModal()
  }

  disconnect() {
    this.destroyModal()
    this.#removeCacheControlMetaTag()
  }

  closeModalOnEscape(event) {
    if (event.key === "Escape") {
      this.closeModal(event);
    }
  }

  showModal() {
    this.element.classList.remove("hidden")
    this.element.classList.add("flex")
    this.modalBackdrop.classList.remove("hidden")
    this.bodyElement.classList.add("overflow-hidden")
  }

  destroyModal() {
    if (this.element) {
      this.element.classList.add("hidden")
      this.element.classList.remove("flex")
    }
    if (this.modalBackdrop) this.modalBackdrop.classList.add("hidden")
    this.bodyElement.classList.remove("overflow-hidden")
    
    if (this.turboFrame) {
      this.turboFrame.src = ""
      this.turboFrame.removeAttribute("complete")    
    }
  }

  closeModal(event) {
    event.preventDefault()
    this.destroyModal() 
  }

  disconnect() {
    this.destroyModal()
  }

  get modalBackdrop() {
    return document.querySelector("#modalBackdrop")
  }

  get bodyElement() {
    return document.querySelector("body")
  }

  get turboFrame() {
    return document.querySelector(`turbo-frame#${this.modalIdValue}`)
  }

  #addCacheControlMetaTag() {
    const meta = document.querySelector('meta[name="turbo-cache-control"]')

    if (!meta) {
      Turbo.cache.exemptPageFromCache()
      // or
      // const meta = document.createElement('meta')
      // meta.name = 'turbo-cache-control'
      // meta.content = 'no-cache'
      // document.head.appendChild(meta)
    }
  }

  #removeCacheControlMetaTag() {
    document.querySelectorAll('meta[name="turbo-cache-control"][content="no-cache"]').forEach(el => el.remove());
  }
}

from flowbite.

Flowbite's handling of Turbo is using the wrong strategy about flowbite HOT 9 OPEN

Comments (9)

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent