Testing for duplicates as user types

I’ve got a field on a page I am building for users to add footnotes. There’s one field where they will enter a letter, and then another field for further elaboration corresponding to this letter.

It’s not easy for users to remember what letter they used in their previous submissions and there’s high risk they will probably re-use the same letter again. I’ve created a simply pop-up to show them what letters have already been used and where so they know the next sequential letter.

What’s the best way to build this out simply in a form? Ideally the form would pre-populate with the next available letter to use, but the next best thing might be for the field to turn red and display a tooltip to tell them it’s already been used.

I assume something conditional will achieve this, but what’s the most optimal solution for real-time duplicate checks?

I am assuming the datatype holds the list of footnotes in some way. If that’s the case, you don’t even need to leave the letter entry to the users. You can just count the number of footnotes and get the next letter from the alphabet automatically whenever someone adds a new footnote.

Now, how do you get the next letter in the alphabet. One way is to have an arbitrary text of alphabet with spaces and splitted by space to have them as list and get the one with footnote count + 1. Something like this: Arbitrary Text("a b c d e f g h i j k l m n o p q r s t u v w x y z":splitted by(' '):item # Footnotes:count+1

Please see the demo below:
chrome_DVqCGJzBWC

Here is my data type for footnote. You can put it as a list to an article or post or whatever place. I did a Do a search for.
image

And here is how I create it on click:

And here is the editor if you want to check more details:

2 Likes

Thanks for taking the time to respond with an example.

The datatype holds two fields, footnote letter and footnote description. I didn’t mention it in my previous post but the footnotes are spread across two separate data types, so both data types of the fields footnote letter and description, and ideally where datatype 1 ends datatype 2 would continue.

Your solution is great, but I’m thinking about if a user needs to delete one footnote, everything should shift up. This is achievable I think, but I need to try and workout if there’s a way to manage this across two datatypes. They are both linked so I can create an expression that reads from datatype 1 and +1 for datatype 2.

You should put your structure then so I can see the actual setup. I didnt understand datatype1 ends datatype2 starts etc.

I think you may not need letters stored in footnotes. If you really want some kind of ordering, add a number order and when displaying, display the letter equivalent of the order. So when some footnote is deleted, you can easily rearrange the order if it is a number.

Here is the structure.

Datatype 1 - “top-level category”

  • footnote letter
  • foot note description
  • project name [linked with datatype 2]

Datatype 2 - “second-level category”

  • footnote letter
  • footnote description
  • project name [linked with datatype 1]

The form itself on the front-end looks like this:

The “top-level category” datatype form

Screenshot 2024-02-03 at 17.58.37

The “second-level category” datatype form
It’s the same questions, but here I experimented with a basic pop-up to display the existing footnotes.

Screenshot 2024-02-03 at 17.58.45

As you can see the user needs to either remember what they put before (or use the pop-up) to remind themselves. The reason why it’s split over two data types is because they each carry similar information but structured differently, but the footnotes are going to be displayed on the same page so that’s why datatype 2 should continue on from datatype 1.

Regarding the numbering, that’s possible, so when it comes to deleting it easier to update, but how will picking up where datatype 1 left off?

I think you still need a Footnote data type separately. Top-level category will have a list of footnotes and same for second-level category. And both of these data types will have numbers starting from 1 for their footnotes.
While adding any new footnote (no matter which category) to any of these, you can do a search for in the corresponding category to understand what number to assign to the new footnote.

This way, the footnote numbers will start from 1 in both levels which means more manageable. Add/remove any footnote etc. Easy calculation in other footnotes.

The main difference will be in the displaying the letters of footnotes. You are going to display the top-level category footnote letters the usual way ("a b c d e .... z":split by(' '):item # top-level footnote number) and for the second-level, you will add both numbers to continue the lettering (something like this "a b c d e .... z":split by(' '):item # top-level footnote count + second-level footnote number).

If the top-level has 3 footnotes: They will be lettered as a, b, and c (because their indices are 1, 2, 3). Then, if the second-level has 2 footnotes. They will be lettered as d, and e (their indices are 1, 2, but to display the correct letter, you will add 3 to both numbers to get d, and e). If b is deleted from top-level, all of them will be automatically updated if you update the footnote-index of c to 2.

Thanks for this explanation. It looks clear. I’ll give it a shot.

Is this for the assumption they are separate data types?
So you have "a b c d e .... z":split by(' '):item # top-level footnote count + second-level footnote number ) so guessing that I combine these two means there are two data types, and if there was a third category (which there is), I combine all three for the last one.

The reason why I want to avoid adding a new data type is because my databases and their relationships with each other is already quite large and it can start to get quite complicated as creating a new data type, means there are several other infrastructure related updates I need to make too (new database relationships, API updates etc)

I’m also happy to switch from letters to numbers for the footnotes so maybe this calculation isn’t needed on numbers corresponding with letters. The reason why I opted for letters originally is because numbers are typically reserved for citations/references (which there will be in this document), but these footnotes will be directly under this data so the distinction is clear that the numbers will be for this data only.

I also need to make this for another field I had to create called Ranking ID. The purpose of this is to allow users to simply rank the way in which the categories and subsequent data appear under these categories. At the moment it’s set to rank when created. But when I export this data via the API there’s no sortation so having this rank field will be useful. So this footnote exercise will also be applicable with this rank.

Yes, if you need more categories, you need to add them up in previous layers.

1 Like

This topic was automatically closed after 70 days. New replies are no longer allowed.