Looking for some quick advice

Wappler General How To
#1

Most of the development I currently do in Wappler is for admin systems with relatively complex forms for surveys and data management.

When I started doing this I tried to keep the number of pages to as few as possible, using modals for inserts, updates etc.

This generally works very well and keeps things nice and simple (and quick) for the user, but, as these forms get more complex, keeping everything organized on the page becomes more challenging in Wappler with many instances of Server Connect and associated components all loading on 1 page. Although everything seems to run pretty fast I’m not sure it’s the most efficient way of doing things.

Is what I’m doing really best practice and is there potentially a better way to do it? I want to try to avoid having to load new pages for inserting/updating records but I’m not sure modals are the best method.

Many thanks for any advice.

#2

I’ve found modals work well and build similar apps to you. Some of my pages have a dozen modals or more and it all works very well.

Another thing to consider is to create an SPA (single page app) which has the performance of a single page but everything is actually in separate files. There’s lots of info on this in this forum.

1 Like
#3

Thanks - I’ll look into that.

#4

Hi there @stoyleg!

Your post is on such an important topic that I think many of us have just stumbled around finding solutions to.

My app is a massive SaaS product - probably 30-40k lines of HTML. I have it all as a single index.php page which references about 20 SSI includes, which all load when the user goes to index.php. I’ve had lots of people tell me I’m crazy but it all works just fine… takes a few seconds to load the page then it all flies along.

So for source code organisation I just have those 20 SSI files, and about 200 Server Actions, neatly organised into folders.

The single most important thing for performance is to optimise what you get from the server to be exactly what you wish to display on the page. So for example if you are displaying orders which also need to reference tables of contacts, suppliers, customers, invoices, payments etc then create a view in your database called ‘view_orders’ and gather together all the required text to display in that view. What really slows things down is when you go and get each of those tables and assemble the data to display on the client side. I’ve been there and it hurts. I’m going through my app now and optimising everything with a view and often getting 100x speed improvements!

The details of how to do the views are below.

Good luck!

Antony.

3 Likes
#5

Just curious as to the reason for using SSI when you are using a single page?

#6

Because a 40k line file is too big for either Wappler or my brain to manage! :exploding_head:

1 Like
#7

That’s why we have a thing called SPA (Single Page Apps) where you use layouts and views to split the content of the site in different views.

SSI(Server Side Includes) are used to display common elements across different pages such as navbars, headers or footers.

But last time I advised you to use SPA and do the heavy work on the server side you told me not to tell you how to build your app :wink:

6 Likes
#8

Well Teodor, the reality is that I never really got to understand how SPAs work so started to build my app with SSIs and all works well.

As the oldest saying goes:

If it isn’t broken, don’t fix it!

#9

That’s what my mother used to say as she was toiling over a hot copper on washing day.

3 Likes
#10

I say that every week as I do the same, Ben.

Can’t beat washing day.

1 Like
#11

Hey Antony, here is a good explanation of why SPA (with code-splitting) are good, their purpose are to load only the required components/pages when the user is visiting your site/app (the components can also be cashed individually): https://www.fastly.com/blog/code-splitting-and-minimal-edge-latency-the-perfect-match

#12

We love SPA and have built almost all our Wappler apps as SPAs across PHP, ASP & NodeJS.
It takes bit more work to get them right - but the nifty performance on client side makes it worth it.

For your existing setup, using CR (conditional regions) will contribute positively to client side performance - but it means that all your existing references on Wappler side will have to be updated as well.

Agree with Antony - don’t fix what’s not broken.
But if you feel things are complex - keep a keen eye out. While SPA will be a big change - but adding CR would be much more within reach!

1 Like
#13

Off on a different tack, as i dont want to get involved in the SSI/Views/ Partials debate and want to add something new

Most of my work in internal company management systems, i actually do very little “public” sites (which is just as well as I am not a brillaint designer)

However i like to keep the code tidy and be able to work with specific portion without the others being sprawled for miles up the screen.

I use “sections” a lot, it’s a great generic HTML element which can be used to compartmentalise your code like folders

So i create sections to hold all server connections for example, one for modals, even nesting them if needed. This allows you to collapse what you don’t want to see on what you need to work on.

So my collapsed app connect may look something like this

image

and i can open/ close the relevant sections as needed

6 Likes
#14

Thanks for the reply - it’s encouraging to hear that others have been thinking about best approaches, and that I’m kind of on the right track. I’ve also been using views to join tables and perform many of the required calculations - it seemed like the best way to do it but great to get confirmation from others.

1 Like
#15

This also seems like a good approach to keep things more organized - thanks!