tech-systems / panes

🎉📱 Create dynamic modals, cards, panes for your applications in few steps. One instance – Thousands solutions. Any framework and free.
https://panejs.com
MIT License
687 stars 40 forks source link

[FEAT] Fixed Footer – content fixed to the bottom of the screen #240

Open Toeler opened 4 months ago

Toeler commented 4 months ago

What are you trying to add to Cupertino-Pane? It would be good if there was a way to add content within a pane that was fixed at the bottom of the screen, no matter the position of the pane breakpoint.

Describe your feature request detailed My use case is a Reply button/text input that needs to sit at the bottom of the screen when the pane is opened. If the user moves the pane from medium to top then the button/input should remain at the bottom.

I attempted this with the offsetBottom parameter and having the button/input be separate to the pane, which works when the pane is at the top, but when it is scrolled down it is rendered over the top. I also tried to use fixed positioning on the button/input when within the pane, but the issue is that the fixed positioning on the pane, combined with the transform, means that any children with fixed positioning are relative to the pane, and not the viewport (https://developer.mozilla.org/en-US/docs/Web/CSS/position#fixed_positioning).

Is there an alternative at the latest version?

[ ] Yes (descripe the alternative) [x] No

Is this related to an issue?

[ ] Yes (Give a link to the issue) [x] No

roman-rr commented 4 months ago

Thank you @Toeler I agree, there is a demand for a fixed bottom bar feature. It will be included later. For now, you might try using the topperOverflowOffset ((docs)) to reduce the scroll area viewport to the height of the button. If that doesn't make sense, please create a demo on JSFiddle or a similar platform, and I would be happy to help you.

Toeler commented 4 months ago

Hi @roman-rr. Here is a jsfiddle with an example: https://jsfiddle.net/sptjaobe/1/

It looks like your suggestion of topperOverflowOffset does help when the pane is at the top breakpoint. But my requirement is that the button is also fixed to the bottom of the screen when the pane is in the middle breakpoint.

I can see how it might be possible using some of the hacks from the Overflow Top-Middle example. But the requirement to show the button at the bottom of the screen even during the drag wouldn't work with that solution. (Also that hack resets the scroll position, which isn't desirable).

roman-rr commented 4 months ago

Please confirm such scenario @Toeler 1) Bottom breakpoint: comments not visible. Button not visible. 2) Middle breakpoint: comments visible, but not scrollable. Button not visible. 3) Top breakpoint: comments visible, scrollable, button visible and always fixed on the bottom.

This is correct? Or button visible and fixed on middle point to?

Toeler commented 4 months ago

@roman-rr My goal is to have the button visible and fixed on the middle breakpoint. And in addition to that, when dragging from middle to top, the button is still fixed to the bottom of the screen.

roman-rr commented 4 months ago

@Toeler Please check this revision and give me some feedback https://jsfiddle.net/romantonoff/0kz8efsL/

Toeler commented 4 months ago

@roman-rr Yes, that is the behaviour I am after. But my preference is that the component that defines the content of the pane also defines and controls the button. With your proposed workaround, I would need the hoist the reply button to the component that shows/hides the sheet and then add logic in there to also show/hide the button.

roman-rr commented 4 months ago

@Toeler Would you like to define bottom bar like so ?

<ion-drawer>
    // some content

    <div class="bottom-toolbar" footer>
      <button class="btn-reply">
          Reply
      </button>
    </div>
</ion-drawer>

When we just set attribute footer and than it will be converted to fixed footer. Is that correct? Or you have other ideas? Also, how about opacity transition? Is that smooth enough?

Toeler commented 4 months ago

@roman-rr If that fits the style of the library then yes I do like that approach the most. Another alternative could be to pass the class in at a JS level as a property.

As for the transition, that depends on the goals of the library. Yes, I need it visible at Mid and Top but not Bottom, but perhaps somebody else would want it visible at Bottom too. As a default, I think the opacity transition is great. An option to configure it could be beneficial for those that want to change it.

If you would like, I could work on a PR if you know what the library would like to offer.

roman-rr commented 4 months ago

@Toeler Welcome to make a PR. You might try to make as you like it, and I will complete it afterwards before merge.