dsfai2020 / Task-and-Nutrition-Manager

An agile planning application that tracks tasks, ideas and nutrition goals. This app is designed to assist with everyday productivity, progress tracking and fitness.
1 stars 0 forks source link

[RESOLVED] Duplicate blank cards keep appearing at init or refresh #70

Open dsfai2020 opened 2 months ago

dsfai2020 commented 2 months ago

Describe the bug Whenever I'd refresh the page. Cards with n index of 0 or 1 would typically duplicate as blank. A conflict would occur between two mappings rendering on the page. By default any cards from the local storage are mapped using their index. Also any changes to ANY card automatically save to the local storage. ALSO, whenever the page would render, a blank card would be created with a new index of 0. This would constantly cancel each of the card states out. The bug occurred because my default population cards had an array they populated off of through an iteration counter. This is so that anytime I press the button to add - it would generate a new card with a unique counter as its ID. So if a new card was created it would use a counter to generate a card with that as its index. But conflicting with this was the fact that another mapping was set to detect any local storage with the indexes and apply the props as attributes to the cards. So in essence I'd have 2 cards on display both linked to one primary key (index 1 for example) and battling over state dominance. Since the blank card would be rendered AFTER the local storage (by process of scripting order) it means that the new card with a 1 as its index would override the previous one. The thing is that it wouldn't change the contents of the other card. Both cards would save their state, upon change, as the local storage value because they were wired to the same key. So if I ever had a card with the number 0 or 1 as its index in local storage, it would create this issue at start up. I'd get duplicate cards with conflicting values attempting to gain control of the same key. Why was this happening? The answer below.

It happened because I had a script that mapped using the counter and a variable called someList, which was basically a holding tank for iterations. What I'd do for each iteration, is increase the counter and append that counter to the list. I used to the counter as a means to id or index these new cards.

Eventually I made it so that the counter state was actually saved into the local storage so that the count wouldn't start at 0 each time...applying the incorrect index to new cards...which played a huge role into why cards were overriding with an index of 0 or 1

Not only did that cause confusion but it also required a lot of testing with what was happening on the local storage side from both the child and parent components.

What ended up being the problem

On the parent side of the component the variable that I'd been mapping someList actually started with a number in it.

someList=useState([1])

This meant that by default a card would be generated. It also meant that by default, since card was generating, that the counter and indexes being applied (prior to the saving of counter to the local storage) was always starting at 0 or 1.

By changing the code to simply [] a blank array. It meant that the component would only render an iteration if there was SOMETHING to iterate off of.

To Reproduce Steps to reproduce the behavior:

  1. Go to '...'
  2. Click on '....'
  3. Scroll down to '....'
  4. See error

Expected behavior A clear and concise description of what you expected to happen.

Screenshots If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

Smartphone (please complete the following information):

Additional context I wasn't really concerned with what numbers actually were in the array of someList. I was more concerned with the fact that it kept triggering. I was also able to nail down some HTTPS like requests to the Local storage to handle deletions. Basically if I pressed the delete button on a card that could was apply a new status attribute that saved into the local storage as "delete" and this would also trigger its removal from the local storage as well.