I've been discovering Wappler for a few days. Until now, to develop web applications, I use VueJS and more specifically NuxtJS.
I'm quite interested in Wappler, but there are some things I don't understand:
I understood that to retrieve data, you need to use "Server Connect" and have created an API route beforehand. I'm able to retrieve my data, but I'm encountering a problem: The data is loaded via an API call once the page is loaded, so on the client side, and it's not "inserted into the page directly at the initial load of the page." So in the end, I have an empty HTML source code for the page, and if my "Server Connect" call takes 1 or 2 seconds, and the site's theme and logo are loaded dynamically via this data, the user will have to wait 1 or 2 seconds for everything to display. I would have liked server-side rendering. I saw the two tutorials on SSR, but they don't explain how to make the data available in Wappler's editor for loops (it shows how for SEO meta, but not for the page content).
It is stated that Wappler is a Low-Code solution, but from what I've seen so far, it seems more like a no-code solution. I haven't found a way to write my own code (I'm not just talking about HTML, but more broadly).
Is there a kind of "Store" like Redux, Pinia, or Vuex to store data that will be used throughout the application? So I don't have to reload them every time.
Wappler editor is not prepared to handle server-side rendering aside from the very basics. Doing a for-loop using server-side rendering is not something you'll find a tutorial for, as the editor doesn't handle that (I think I did it once, but it's not intuitive). Injecting the site's theme and logo is not complicated, you create a Server Action to find the site's theme and logo, and then you configure your page ("App"), section "Server Side Data" and you select that Server Action. This way the Server Action will be run upon page load, before the page is served to the browser. And then you just have to put in the HTML the corresponding EJS tag to echo the variable (there's a button in Wappler).
Writing own code is writing a Wappler custom extension or formatter, meaning you can build custom steps or formatters. You can also build front-end components but I'm not familiar with it.
This exceeds my expertise, someone else might be able to answer this.
I understand points 1 and 2 better now. I'll look into custom extensions.
Regarding point 1, I indeed found this solution. Does that mean I need to create a Server Action that will return all the data I need? The theme, and all the other useful things at startup?
Regarding point 3, I'll give you a concrete example. Maybe I still have a view too oriented towards VueJS, and it’s managed differently with Wappler.
Let's imagine I need, across all my pages, two pieces of data: stores and articles. I need the "raw" data to use them in different ways throughout the application. How can I load all this data without needing to include a Server Connect in each page for each of these data?
In fact, here's the real process: The user visits the site. I need to retrieve the current domain. This domain will be useful to call an API that will return the corresponding company (it’s multi-tenant). This company has an ID that I need to save because it's what will allow me to retrieve that company's data (the site theme, logo, data, etc.). Once I have the company, I need to retrieve the articles and the stores, which I will need in various places.
My question is how to do this process in the right way, in the cleanest manner? Should I create a Server Action called "initial_data" and an App Action "initial_data" that calls the Server Action and include it in my layouts?
Yes, once the company ID has been retrieved based on the domain name, the ID can be stored in the client-side session or local storage to filter and retrieve further data.
If a user login is required to access the articles and store, then a server-side session can be used to filter data based on this session value.
Yes, you just don't use a Server Connect (as that's a client-side API call).
Regarding point 3, you can place a Server Connect in your main layout, and that data is preserved across page changes if you use SPA-style routing (HTML attribute "internal" in the links). I'm sure there are also other ways such as using a "Data Store" or something, but I'm not familiar with those Wappler components as I'm more specialized in the back-end, and you also risk finding some Wappler bugs (namely, lack of visual guidance when selecting variables) the more exotic stuff you do.
However, here’s the rendering in the editor. I hardcoded the domain in the Server Action for testing, it's work in browser, but it seems like it’s not being called in the editor... I end up with a nearly empty page, which makes it hard to modify the page and see the rendering.
With Server Connect, it works better, but I’m back to the initial problem.
I'm afraid the behaviour you describe is expected behaviour
If you're lucky, with enough experience you might find some clever tricks to show some default (e.g.) logo but hide it if you detect some variable was successfully injected through the EJS tags/expression. The Wappler editor doesn't run/evaluate the EJS tags.
I think you got on a wrong foot here, started seeking for server side rendering only while in Wappler the primary and most is easy way to do data binding is just client side.
I have always said to people, the hardest thing about Wappler is unlearning your current workflow.
Follow the Wappler workflow, don't try to apply your old workflow to Wappler
You do not have to create route, simple connect the API action from your page using the picker
You implement you own code via custom extensions, (see this Youtube series) but you will rarely need to do this, wappler does all the hard work visually.
After doing some research, I see that you're right. In fact, I wanted to do server-side rendering because my API can take a bit of time to respond, and I would end up with a "design-less" page for a few seconds while the application waits for the response. And server-side rendering helps solve this problem. But if you have another solution, I'm all ears.
I agree, haha! That’s the problem, we often try to stick with what we know, but in the end, technologies often work differently!
I don't know Wappler's limits well enough, so I thought, "If I can write my own code, then there's probably no limit." And I'm more used to coding; no-code is a bit slower to work with.
I suppose once again I have a vision too focused on what I currently know, and maybe it's not necessary in Wappler.
Hey @FougereBle
Welocome to wappler community. Following our dest brothers that already pointed out a few very useful things, I would like to talk about your maon concern...
Your api's may take some time to respond.
If that is your problem then I would say to check why your api is taking so much time to respond...
If this is caused on wrong building of the api then you just give a little time to make it more effective and more "to the point" (I don't think that thisis the case based on your coding experience).
If this is because of your spi' complexity, then you could probably "break" it in two or more apis.
Then in your page, add the according serverconnects and let them "feed" your page content.
If we still talking about apis that take too long to respond, then you can always have on your page a preloader (full screen, hiding the page contents), that can inform the userof the loading progress and finally hide the preloader amd let the content show.
(But in any case, let the user wait viewing a preloader for several seconds, is not a good practice in our daysdays I suppose)
Wappler is giving you all the tools to specify whete is the problem (if any) and then act accordingly in each case
Try avoiding to code so much when certain things can be made and handled through wappler ui/components/techniques
I had (and still may have) these concerns and I know what you are going through)
You can cache your server connects to local storage.
You can also chain multiple server connects together, one after the other using the "Dynamic Attributes" of each server connect. Do an "On Success" and make the logo the first server connect, then load other data afterwards. Basically there are multiple ways to optimally load data.
You could also create a "loading" overlay div until the Server Connect has fully executed.
It's a low-code/no-code, it really depends on how complex you need.
Wappler provides all of the "building blocks" you need. Everything from getting server methods to IP and User Agent using the Browser component on a page or components like cookie and local storage. It's extremely powerful and just takes time to fully understand all of the capabilities and how to enable them for your needs.
The documentation is sometimes hard to follow or non-existent, but the capabilities to build nearly any type of website or app (server based, SPA, mobile, and desktop).
