I bought the book and I really like it. Well done @petter!
What I didn’t like as much was that my bank flagged for suspicious activity and deactivated my credit card.
I didn’t get a strange feeling at all when paying but if it’s happening to more people it might be worth considering a payment provider switch.
Several users (a small minority, but still) have reported the same thing actually. Gumroad (while definitely legit in itself) does seem to struggle with transactions being flagged by some banks, for reasons I don’t know at the moment unfortunately.
I’m sorry if it caused you problems, hope it worked out with the card. What I’ve heard from others is that the bank would call them as an extra precaution before accepting the transaction, but this is the first where the card has been dectivated to my knowledge.
@petter What an excellent read! Well written, clear, and light. And it’s good to get a collected pack of knowledge since however smart and helpful the forum is, it can be hard to put all good pieces one gets together. You also blend conceptual thoughts with hands-on how-tos in a brilliant way.
I’ve been on Bubble for a while, but definitely picked up some tips. Favourites are the error message popup and back end triggers.
A few Qs:
A :count is performed on the server and :filter in the browser, but if the :count is after :filter the :count is done in the browser as well (which makes sense). Is there somewhere to read up on where the parts of a Search are performed and depending on how they are combined?
A long the same thought line; I do use a reusable element to host a couple of sub routines (glad that was considered a good practice ). It runs a workflow on page load that populates a state with data that is used by the main page. However, that workflow is run after the page is loaded so I need to have conditional workflow on the main page that fires when the RE’s state is not empty. This leads to my question. Is there somewhere to find the exact order of execution of things on page load?
Could there be an issue with error handling when using Background triggering? I the example the user might have entered an email that exists. This, of course, could be pre-checked, but my thinking is more general on how non-successful actions can be caught and handled
I’ve been thinking about this myself, and looking into setting up a table of how different operators are performed. I’ll have to get back to you on how exactly I’m going to approach this: either as a blog post (freely available) or as an addition to the book.
My initial thought here is simply to use the debugger and go step by step over it from page load on. I’m concerned that the result of that may be a bit misleading though, since the debugger isn’t entirely accurate in how it presents the steps. I’m doing a follow-up with Bubble digging more into some book details and questions from readers, I’ll be sure to include this one.
That’s a great question! I don’t know the answer at the top of my head, but it makes perfect sense to include in the chapter as a caveat. Let me know if you do any research on this, and if not I’ll look into it when working on the revision.
Thanks Petter for coming back on my Qs. Inspired by your book and answers I feel energised to explore and discover more on the intricacies of how Bubble really does it’s excellent job. Let’s stay tuned.
Maybe someone at Bubble want join and set us in the right direction.
I keep coming back to the loading order, both on page loading, but also afterwards. When I really need to be sure data is loaded before, let’s say, a calculation I tend to force it by doing it in the workflow. I also tend to check for when a crucial RG is populated with a conditional workflow (RG:count > 0 and RG not loading).
PS. Awesome that you have sessions with the Bubble techs!