If you search in the forum you’ll see that form_show being fired twice is a known issue.
If the server call has to be in form_show (versus init, or in some user triggered function), and calling it twice is an issue, you can put some code in the function that tracks when it was last called, and sets a reasonable timeout before it’ll call again.
How many times is your print printing in the console? That will tell you how many times the server call is being made.
The anvil.users.get_user() call is likely making a call to the server to check the session (at least the first time its made in an app, I don’t know if there’s caching involved there). That might account for the second rpc call.
Ahh, I didn’t know anvil.users.get_user() would also generate RPC. Now everything is clear.
So should I fetch the user once after logging in and keep this information cached for better performance? If so, where is the best place to store such data?
I wouldn’t worry about it, anvil.users.get_user() really just gives you a lazy row from the users table (it has some restrictions for security beyond a normal row but that’s irrelevant for this)
When you get a row object from an anvil table it’s lazy and starts out with no info. As you request the info it populates the data, if you store it in a variable, obviously you can use it later, if not it’s like any other iterator/generator object and goes away. If you put a whole bunch of rows in a lazy row iterator, it will stream/chunk/cash the data in various ways so you don’t have to make an RPC call for every single row.
I guess what I’m trying to say is Anvil is pretty slick and already optimized for they day-to-day running a webpage stuff.
I don’t waste time optimizing until I need optimizing.
If an RPC it takes longer than one second or if there are hundreds of RPCs, then it may be time to have a look at them. But I use Anvil because I don’t want to waste my time thinking at such low level.
I tend to use that basic approach for most apps to hold data that changes infrequently, and then add specific features to it as needed. It could be extended to include the current user, for example.
Also note that passing the current user to the server is both unnecessary, and a security risk. Instead, just execute anvil.users.get_user() on the server itself, when executing add_device. So in this particular instance, the call can be eliminated entirely.