Filtering Issues

[foliodc]

I am having two issues with Filtering a static collection list:

I would like to filter a list of events by the state that the host organization is in. The data looks like event item > org item > org state. The static collection filter option only goes to the second level {org item}. Is there a way to access deeper levels? I could add the state to the event directly when created, but would rather have the data in one place.

The second issue is more design-related. I would like to have a sticky section at the top with filters. When you are further down the list and want to filter, the page becomes shorter and you lose your place. One solution may be to return to the top of the section when the filter is clicked. Is there a no-code or javascript method to do this? It would need to be part of a no-code workflow. The best solution would actually maintain your position relative to the list, but this may be too difficult for now. Here is a loom video explainer:

Thank you!

[khairul]

on the first issue. You should be able to access the org state if it is not empty, you will get its object key then.

second issue, I think you should set a min height when the list is too short. Then you will still be able to have the sticky section on top

[aurelie]

I @foliodc , for your point 1, this is indeed not possible at the moment. This is a known limitation, and having deep filters is currently on our roadmap.

[foliodc]

I found an easy workaround in Xano for the frontend filter depth limitation. I used a Join and Eval to add the info to the top level. May not work in all cases.

I would still like to solve my second issue. When someone filters a list, can I send them back to the top of the list? Is there any way to move to the top of a specific section using a workflow +/- Javascript?

[khairul]

yes. id the top section. Then make a workflow link to the specific section on the page.

EDIT: you don’t need to id them. Just change the name of the section

[Mael]

You can also do it in JS with this function: document.getElementById(“id_of_your_section”).scrollIntoView();

[foliodc]

@Mael Thank you for your reply. I tried that custom javascript in the workflow, but I get a syntax error. Maybe I’m missing something, tried some searches online.

Section is named ongoingSection (tried a few names). The workflow is on the button, “By Gallery”

[Mael]

It’s easier to do it in no-code like khairul show you. When you select link to page, you can choose a section

If you want to keep JS, if you have the workflow on your button, the id of the section should be on the same page where you want to go

[dorilama]

I think the syntax error is because the quotation marks you are using for the string of the element id.

It looks like the code is using left and right double quotation marks “ ” for the string, but it should use the neutral quotation mark ".

The correct code is: document.getElementById("id_of_your_section").scrollIntoView()

[foliodc]

@Mael I had really unpredictable behavior when using the no-code method while triggering a workflow. Sometimes it would run the workflow and change the variable only or move only, sometimes nothing, sometimes both. Decided it is better to combine with workflow. Ideally, the change page action in workflow would allow section input. I don’t think it’s possible with parameters (?)

@dorilama Thank you! Unfortunately this results in a different error:

Not pressing, just curious. Thank you

[dorilama]

It’s because it can’t find the element in the page, and you can’t call scrollIntoView on null.

Are you testing this inside the workflow editor or in preview mode?

The context of the workflows is different if you execute the in the workflow editor or in preview.
The document in the preview is your app document, while in the workflow editor it’s the weweb’s editor document and your element is not here.

Because this action is scrolling the page there is no real use in testing it in the workflow editor.
Try testing it in preview mode.

If you still get the same error then it’s because your element is rendered into the page after the execution of your workflow. This can happen sometimes with modals.
If this is the case you may need something different to select your element, for example an intersectionObserver like in this post.

Anyway accessing an element directly in a vue app is considered an anti-pattern.

In your nocode try did you bind the id of the section to the link? Maybe this can have rush conditions and work erratically.

Anyway an action for scrolling inside a workflow can be useful.

[aurelie]

Just for information, you can do wwLib.getFrontDocument() rather than just document to be sure to always target the app document (iframe in the editor or the published app).