I have just finished an application which, on loading, checks for a query-string in URL, does some checking and if al is OK, inserts a row into a collection. Because this happens without user-interaction, I thought I would run the risk that, with the new rendering, the row would be inserted twice. So I put that inside an if-statement, checking the rendercycle.
To my surprise no row was ever written: rendercycle always returns Nan (which, per documentation means rendering has finished). It´s obvious that I am doing something conceptionally wrong, but I have no clue what.
Below the main code block:
$w.onReady(async function () {
let user = wixUsers.currentUser;
let userRole = user.role;
if (userRole === "Visitor") {
wixWindow.openLightbox("Err:NoConectado");
} else {
validatorEmail = await user.getEmail();
let strFullQuery = wixLocation.query;
let strVoucherId = strFullQuery.vid;
if (strVoucherId) { // we have an incoming ?vid=xxxxxx
let objVoucher = await fnChkVoucherNumber(strVoucherId); //try to get this voucher number
let count = objVoucher.totalCount; // do we have it?
if (count > 0) { // if so, now check dates (status)
let numVoucherStatus = fnChkStatus(objVoucher);
let thisRow = objVoucher.items[0];
let strVoucherRefId = thisRow._id;
fnDisplayValidation($w, numVoucherStatus, objVoucher, strVoucherId); // show red/orange/green
// if (wixWindow.rendering.renderCycle === 1) {
fnInsertRow(strVoucherRefId, validatorEmail, numVoucherStatus); // write row in VouchersChecked, but only once
// }
} else {
fnDisplayValidation($w, 0, null, strVoucherId); //set "Voucher does not exist (also red)"
}
} else {
$w("#boxInputVoucher").show(); // if no incoming voucher thru URL, then ask it first
}
}
});
Is there anyone who can shine some light onto this?
Hay Giri,
On first glance, your code looks fine. We are checking if we have a problem in our system, will update soon
Hey
I don’t think that you can actually user server side rendering when also using wixUsers and wixWindow because that is a client side thing I would presume. But Yoav should know but this would be my first guess. I would move all code into a backend function in a web module and then send users id into that function together with the query parts.
Yoav, thanks. Andreas, maybe that is my conceptual error. I believe(d) that rendercycle meant just that: how many timed the rendering has ran. I thought it did not mean “server side”, just that it could be client or server side and with rendercycle you just prevent the insert to be performed twice if rendering is done twice.
Hey, you are right but 1) I don’t think rendering is available on desktop yet, just on mobile. 2) I think that in your case you should check for environment === desktop like the below code shows you.
if (wixWindow.rendering.env === “browser”) { $w(" #myText ").text = local.getItem(“key”); }
In this case you would only run your code in the browser and not on server and you need to run it in desktop / browser so that you can use the functions/library you use I believe.
Whoh. Never thought of that. That would mean that, in order to run the same code on both Desktop and Mobile, you would have to accompany every rendercycle check with a check on formFactor?
No the browser check is always on desktop/mobile browser / clientside, the other is serverside. So only one check, if rendering.env === “browser” you are on client side. But if you want to speed up code make webmodules and run all time consuming work in a webmodule, way faster
Andreas, what Ysrael lately proposed to me I repeat to you: “we should have a beer or two together”. I highly value your comments, but I still have a couple of black spots in, probably, the conceptual understanding of the new rendering. Here we go:
I assume from documentation that:
- we have no influence over the decision making model that Wix uses to run something client or server side (unlike something like runat=“server”): the properties .rendercycle and .env are read-only
- the decision model is opaque to us (which piece of code runs where)
- if you can run something at client or server, you have 4 combinations. We can, for obvious reasons, exclude the option “not at client/not at server”)
- from documentation, I deduce that we can eliminate another option: server only
- this leaves us with two possibilities; at the client only or both at client and server
Now the deduction:
the combination of 1 and 5 dictates that the use of the .env to regulate whether to write something to a collection is flawed: we cannot control the process and if you write something from “browser” to a collection, the same might already have happened on “server”. That is why Wix offers the .rendercycle: you don´t know if it is going to be rendered client side or client-and-server side, but you DO know you only want something to take place only once (rendercycle===1)
Considerations
It might be so that the rendering process is only implemented for formFactor=== Mobile. That would mean that on “Desktop”, .redercycle always = ? and .env always “Browser”. Maybe that is my problem, that .renderCycle always returns Nan on desktop. I do not know. I have a presentation on Friday and with the .rendercycle commented out, it is good enough for that day. I will test further during weekend/next week.
I would appreciate anyone to comment on my assumptions and deduction (like 1:false [comment], 2: true, etc), so I can wrap my head around the concept better. Thanks.
EDIT: 2 more things that I (possibly mistakenly) deduced: The following checks would be pretty useless:
- if (…renderCycle===2): this code might never be executed (see assumption 5)
- if (…env === “Server”): this code might never be executed (see assumption 4)
You can use server side only but you cant combine server side only with functions that depend on browser such as users / wixWindow I believe. So you can choose but not combine. Beer? Hell yeah 
Yoav, any news, for I am wracking my brain to find out why it returns Nan?