How to build a Wordle Clone with Bubble - Part 2... or not

Instead of part 2, you get 3 videos.. wot?

Ok, you may have seen my last Wordle article about how I set up the User Interface for my Wordle clone on Bubble, and have been waiting for part 2, which was intended to wire up the backend to make it work.

Well.. since then, things have happened. The Magestical people at Coaching No-Code Apps used the Wordle app as an example for a 3 video series about how to build it with Bubble.

The 3 parts are listed below and I highly recommend spending the time to watch them, and even follow along with your own build.

Part 1

Part 2

Part 3

So, what does this mean for my Part 2 article of the Wordle build?

Well.. I’m not doing it.

…

Don’t be sad.

This kind of thing happens all the time with computers, things change, new information comes to light, and we pivot. In my case I’ll pivot to writing a bunch of articles about other stuff, like API’s.

The videos above are excellent, so I don’t think there is a lot of value now in writing up my own version of the final part of the build.

However.. let’s have a quick chat about some topics that come up in their videos:

Repeating Groups

They chose to use repeating groups for the structure of both the guesses grid, and the keyboard rows. I chose not to.. why? Because I knew that Repeating Groups don’t display ‘empty’ data. By which I mean, it’s hard to make Bubble set up a whole grid before there are letters to iterate through as the datasource.

The method that they used to get around this limitation was by using a series of numbers provided by the ListOfNumbers functionality from the Toolbox plugin. I did some experimenting with this early on, but ruled it out [in error] due to complexities of later adding a different data type [text] than the cell was expecting [number]. Coaching No-Code Apps got around this by just using the Numbers as the data source for the RG structure itself, then having other layers of groups within which hold the data. Nice.

Physical Keyboard

Coaching No-Code Apps used an experimental plugin called Mouse and Keyboard Interactions. This is really handy and I plan to test with it. One downside was the lack of support for the Enter key which forced the use of the Spacebar in their demo. My method was to load a little javascript at page load which set up a ‘listener’ for keyboard events:

along with this ‘Javascript to Bubble’ element added to the page from the toolbox plugin, with this configuration:

The upside of this approach, is that the ‘Mouse and Keyboard Interactions’ plugin is not needed, and the Enter key can be processed. However, this approach also accepts any key press, such as numbers, special characters etc, which are not valid inputs in the wordle game. To get around this then some Regex processing would be required to filter them out. Overall probably the Mouse and Keyboard Interactions plugin is a simpler approach.

Lack of support for duplicate letters

Early on I did a lot of testing with states that had a single value, vs states that were a list. During that testing I found that if the state was set up as a list, then the plus-item action was used to add a newly guessed letter to the state, that the letter would not be added if it already existed in the state.. in other words, the plus-item action does not support duplicates.

Splitting States into a List

So.. choosing then to make the state for the current guess just a single value state instead of a list, I could then fill it up with guessed letters, and append a comma ‘separator’, so that later on I could do a split-by action based on the separator, resulting in a list for which I could address individual items, such as item#1 item#2 etc. The downside of this was additional complexity, when trying to compare the word of the day, with the currently guessed word. The video examples above used a nice example of Regex search in that a single dot matched every character, thereby splitting it into a list without needing the comma separator. Smart.

Is the word valid?

One thing not addressed in the 3 videos is a method to check if the current guess is actually a word, rather than gibberish. I managed to implement this check in my build by importing a list of approx 8000 5 letter words into the database. Since these are server-side (in the database), checking the current word against them is a slow (~20 seconds) process, for the first line. After the first line, performance is good due to caching, but it’s not ideal. Having all the words as an Option set is a way around this as they would be served by the bubble CDN which is much closer to the client. In the case of the real Wordle app, they are all client side and visible with the chrome dev tools. Presumably this makes the first install slow, then it’s fast from there on. It’s a good use case for client side caching, as this list is large and also changes very infrequently.

Custom Events

Both Coaching Nocode Apps and I implemented Custom Events. It’s a really handy way to repeat yourself less with your workflows. If I’m noticing I’m adding the same action 2 or more times somewhere, I’ll collate that into a custom event, then trigger that from the multiple places it is needed. Better for app dev speed and better for maintenance simplicity.

OK, that’s all for now. The lessons of this story are that:

• There are always multiple ways to achieve a task. Some are more elegant than others, some are more performant, and all come with pros and cons.

• Rabbit holes are everywhere. Your design choices have consequences, so it’s important to keep an eye on what workarounds you feel you are being forced to make, and if they are too great then go back and review your earlier design choices.

• Even if you know lots, you can still learn lots, keep at it.

fyi my next few articles will be about integrating Bubble with various APIs. Let me know if you have a particular API you want added to the Roadmap.

..Marty