Trying to get ion-footer rendering in a component


#1

I’ve created a few components that handle form submission functionality. In each of these components, I want the form submit/cancel buttons to be fixed at the bottom of the view, much like the functionality available via <ion-footer>. The submit button needs reference to the variables + methods in the component for [disabled] + (tap) functionality, for example [disabled]="!formGroup.valid" (tap)="submitForm()"

If the component is a child of <ion-content> then there is no way to add<ion-footer></ion-footer> as it will be contained within<ion-content>, instead of below <ion-content>. At first glance, having <ion-footer inside <ion-content appears to view properly, the rendering can be buggy especially in scroll situations. I went as far as setting a force-bottom css class with fixed position/bottom but it looks like the ionic javascript overrides fixed positioning when inside<ion-content, so a pure CSS solution does not seem to be possible.

<ion-content> 
  <a-form-component>
  </a-form-component>
</ion-content>

Any recommendations on how to achieve the desired functionality?

TIA


#2

Are you using ion-nav?


#3

Well, it is November now and still don’t have an ionic solution to make use of ion-footer in a component. The problem being a component sits in ion-content and any dom elements with fixed positioning to bottom are affected by ionic scrolling.

Does anyone have a solution to have a component with form/inputs that lives in ion-content and communicates with a button in ion-footer (the only area to force content in the footer of the page when scrolling)? I tried using ionic Events https://ionicframework.com/docs/api/util/Events/#publish to communicate from a component in ion-content to a button in ion-footer but the implementation gets messy very quickly and is more of a hack than anything else.

I’m just about ready to snap :wink: Please… Anyone. TIA


#4

I can’t think of any way to do this with stock HTML form submission. If you’re not wedded to that, and the concept of “submit” is flexible enough that it could just mean “call method onSubmit() in a page”, then it’s doable.

When I’ve had situations like this, what “submit” means is determined by the page that includes the component, not by the component itself. The component is just responsible for managing input elements and providing a value object and a valid state. Something like this:

<ion-content>
  <form-thingy ngDefaultControl 
    [(ngModel)]="formValue" 
    (validityChange)="formValid = $event">
  </form-thingy>
</ion-content>
<ion-footer>
  <ion-button [disabled]="!formValid" (tap)="submitForm()">submit</ion-button>
</ion-footer>

The submitForm method in the page would have access to the page’s formValue property, which would be updated by the component.


#5

Thank you for the reply.

My problem is that each of my forms and all the associated logic is buried in the component and those components are used on multiple pages. I have it set this way to keep the components clean and individually functional.

My frustration lies in that Angular/Ionic is fundamentally based on building components, yet there is a serious limitation with the Ionic framework that prevents us from forcing a footer at the bottom of the page.

I wonder if there is an easy way to listen for scrolling in a component and reset the components footer css to position: fixed and bottom:0 every time a scroll event occurs. Maybe this would keep a dom element in ion-content forced to the bottom while scrolling?

Thanks again for the feedback.


#6

I get that you’re frustrated, but if you’re going to do this:

…that means that the component’s presence in the DOM needs to be isolated from everybody around it. Imagine if you could do what you desire, and bust out of DOM encapsulation to render stuff in the footer. What happens when you have two or more of these components trying to do this in the same page?

If I were you, I would spend my time rearchitecting so that these components’ responsibility ends at “producing a value object and certifying it as valid”. I think you can still include a lot of business logic in there without having to concern oneself about what “submit” really means.

For example, I often use this pattern when having a component that is capable of either creating a new thingy or editing an existing one. The component doesn’t need to know or care which is the case; but maybe the hosting page knows that the result will go to a different endpoint and/or be presented differently (e.g. only post changed fields).


#7

This is good advice. Thanks for the example as this will help me revise the architecture.