Scroll horizontally with the mousse in web view + Conditional Renderer native vs web🧐

Dragging the mousse left/right does not help to scroll horizontally my repeated cards within the scroll view component (horizontal scroll enabled!).
Looks like there used to be a thumbnail carousel component but it’s gone.
Any tip appreciated!

Anyone with a clue or is there really no hope?

(Tested in desktop web preview)

I guess they left the carousel in for those like me with it already installed for legacy reasons. The component plug for looking it up in the marketplace is custom-409e7bd8-4c2f-4ca2-a6e9-9eb696970215. However, it showed no results for me either, so it must’ve been formally removed.

As for horizontally-scrolling scroll views, I just tested it as part of my community contribution for the year and it still works, just buggy. I had to set all three top fields to true, including Show Vertical Scroll Indicator. However, by setting a firm height of 100px and width of 100% (works fine with pixel widths too) it displays fine without the vertical scrollbar. Of course, set the Layout to Horizontal, but you folks knew that. :wink:

It does NOT work with Show Vertical Scroll Indicator set to false.


1 Like

Thanks for this!
Indeed I do have a scroll bar now, but it’s not pretty and the left/right dragging for scrolling with the mousse is not enabled.
I guess I have to forget about the scroll view component.

I’m not sure drag (presumably referring to clicking in the body of the scroll view and pulling either left or right) or rolling the mouse wheel has ever worked for manipulating the horizontal scroll view (HSV). If it did, I would suggest experimenting with removing the horizontal scroll bar to make it more visually appealing. But I believe that’ll just just break it again.

Ironically, clicking with the mouse wheel in the scroll view to activate the automatic scroll function does work. I’ll bet drag would work on mobile too, so not entirely useless for everyone…

To be fair, HSVs have been broken like that since 2021. :stuck_out_tongue:

Thanks for the tip! Although still not optimal user UX when using the pad on a laptop.

So I’ve resorted to the conditional renderer, which I see you’ve used before. I guess the advantage of it over a simple conditional display is that the renderer will only load the elements (containers) that meet the condition.

However, the wrap overflowing elements option does not work inside this renderer.
The overflowing components go through the left and right margins, hiding the first few and last few components. Maybe you know of a trick, much like the one for horizontal scroll view?

1 Like

No problem, but I’m not 100% sure what you’re trying to do. It sounds like a slideshow viewer (for a product page, for example), in which case, conditional renderers will generally work fine. Perhaps, a square image in a CR with two buttons centered on either side (absolute). You could then bind the buttons to logic to show the next image in the CR, etc. Would work fine, I’d imagine.

If you’re feeling ambitious, you could even try experimenting with the “Animate Component” logic node from the Marketplace to add slide-in/out or fade-in/out-type effects when transitioning to the next image.

You could also try… sliders maybe? Never tried it myself directly, but perhaps a slider as a visual aid bound to logic connected to your CR. Still can’t be scrolled, but is another option.

As usual, results may vary.

As for the the CR’s overflowing issue, I don’t believe Composer allows for any kind of styling (including clipping overflow), which means I’m not sure of a direct solution. Perhaps, you could nest the CR into a container with firm dimensions set (i.e. 512px W x 512px H), and then make sure your images inside the CR match the holding container’s dimensions as well to force the CR to the correct size.

You would then set the holding container to clip overflowing components.

No idea if it would work, but that’s what I would try if I understand you.

I didn’t understand anything of your first reply LOL
But I realize the scroll view within the conditional renderer does work well (native condition).
If this complexe “formatting” works within the CR, so should a basic wrap overflowing option.

I think I am messing up the web condition setup in the CR. What to do next from here?

Already nested inside a container, which is its self inside a simple “card” container.

Just not sure how to setup the second render ID. Unbelievable, always stuck on the simplest things.

I didn’t think you were still doing scroll views there.

To avoid any confusion, a conditional renderer only supports direct visibility of different “sets” of visual data. An example would be the GIF below where we use a CR to control which UI is visible (Security settings vs a user’s Bio) with a click or tap.

Pardon the crappy state of the UI. I’ve been working on bringing it into alignment with the new platform theme!

In a sense, it’s almost identical to the logic behind soft tabs described here, but simpler: Soft Tabs - View components The idea is that, if you’re trying to do some kind of product display carousel, it can be used in a similar manner to fake a slideshow of sorts.

  1. You’ll need a page variable of type ‘text’. I named mine “cv_moduleType”.

  2. Drop your images individually into a CR in the editor. In this case, I dropped in each UI module, such as “mod_bio” in the Tree:

  3. As seen in the image above, bind the CR’s ‘Active Render ID’ to your variable. The Render IDs are values that are set in your aforementioned variable. So I have a button in my tab setup in the GIF that sets the variable to “bio”, and the User Bio UI will show. Likewise with “security” and “account”.

You can swap between the images/modules in-editor or rename the IDs by clicking or double-clicking the list of IDs, respectively. Whatever the default value of your page variable is (i.e. “image1” or “bio” for me), is the image/UI module that will appear to the user upon page load.

Just not sure how to setup the second render ID.

Just drag another component (image or whatever it is) in the CR and double-click the resulting Render ID to change its name to something you want to refer to with the page var.

So that said, I’m not entirely sure how you were planning on using a horizontal SV with your CR. I can’t really imagine a way that would work.

NOTE: Never use more than one CR on a single page. You will almost certainly trigger infinite loading loops and crashes in the desktop preview, and possibly (not verified), in your final build.
Source: Experience.

Nope, sorry I can’t get this CR to work on both conditions (native with scroll / web with wrap overflow).
Works well with native view (render condition #1), where the horizontal scroll does its job.

Web view : wrap overflowing component fails : missing the few first and last images in the repeat list.

Setup seems fine:

Ah, now I think I see what you’re trying to do: Controlling the visibility of one container vs the other depending on mobile phone view vs desktop view?

So if it’s on desktop where you’re having issues, we did get the horizontal scroll working. If you’re NOT using a horizontal SV but trying simply with a container with horizontal layout and wrapping overflowing components, my gut says you might need to give the holding container a firm width and no height (i.e. 400px max width, min width / blank height setting).

Try that because, for the most part, it seems almost identical to our ‘user background selection box’ in which there are a number of theme boxes (containers; “Classic”, “Nature”, etc) each with a number of preview image buttons which do respect wrapping the components with a horizontal layout, as imaged below. In our case, the scroll view is irrelevant – just a means to pack more content in limited space.
Screenshot 2023-04-21 144122

Do you mean to have your “budget” buttons stack vertically with five per row?

If not, could you clarify in greater detail what the overall goal is for that desktop view container. Does it need to slide left and right like on mobile or stack in eventual vertical rows like in the image above?

TL;DR With a third reading of your last answer, indeed, your container having a firm width and no firm height should actually allow wrapping just fine. :thinking:

  1. Also, could you screenshot your formula logic which you’ve implemented to control the visibility of each respective holding container (native vs desktop)?

  2. Is that logic bound to the visibility field of each container in the renderer?

I would assume so, but just double-checking.

Bravo Sir! You’re the expert in handling these types of components. Somehow, I can’t use any of them, I just don’t like how they are setup and I can never wrap my head around these things.

For our readers trying to figure out this component, I’ll answer your other important question:
The dynamic binding for the active render ID is the value of this appVar, which is defined on app launch in the global canvas.
But somehow I feel this is unnecessarily complicated. I could simply bind the active render ID to systemVar.runtime

1 Like

Well done. Glad that worked out. Honestly, it’s just a gut instinct you pick up for some of the… “nuances” of building UIs in Appgyver. :wink:

Since I only build web apps for use with desktop and mobile browsers, didn’t know there was a “Detect native or web”. It’s been a while but we used to have separate UIs for desktop vs mobile on the same page – one scroll view for each view. We would control the visibility of either UI view by screen width. I believe it was the systemVars.dimensions.screen.width formula.

While I don’t have the time to run a test at the moment, were I working on something like you, I would’ve tried binding the visibility field of each container in your renderer to something like the following examples.

Used to show the native version when the screen width is less than 500px:
systemVars.dimensions.screen.width <=500

Used to show the desktop version when the screen width is greater than 500px:
systemVars.dimensions.screen.width >=500

If you feel like it, you could test adapting that formula code for ‘runtime’ and plug it in. Could just break it too. lol

1 Like

The issue I see with that solution is you overload stuff, since all elements for both UI (desktop and mobile) are loaded, whereas the conditional renderer only loads the elements that match the condition.

Don’t misunderstand, we would use CRs today for that too. At that time, there were no CRs yet.

It was more a matter of Mevi pointing out that hidden objects weren’t loaded in memory at that point in time. I’m not really sure on that because it goes against the common logic of both components being loaded in memory to allow swapping on the fly.

Either way, definitely stick with CRs with that kind of fun, folks. The same logic implemented into the vis fields should still work.

Ah, now I remember why we didn’t use CRs to control the visibility of whole page-width/height elements, and that’s because it requires firm set dimensions of internal components to control its own width. In other words, you can’t simply set the conditional renderer to 100% W/H, respectively.

Something that might work is creating a 100% W/H page container, nesting the CR inside, and then nesting whole page UIs inside that. Something to test for, but no guarantees.

I’m just curious if Appgyver actually truly hides hidden components to the degree that they wouldn’t be accessible to frontend hackers. An example would be one UI (whole-page container) showing the normal profile page of a user alongside another UI showing a “Profile is Private”-type interface.

For an MVP, a simple Bool relation in the backend database of “isSubscribed?” is enough to control whether a second user can see the first user’s full profile. But if its possible to expose the full profile container in something like Chrome’s Inspect interface when it should be hidden, then that’s clearly not nearly secure enough.

Kind of would like confirmation from an AG team member, which really only leaves @Mevi. :smiley: But if anyone knows better…