Setting Single-value stores to 'null' breaks Alpine

[colinaut]

Found out that if I set a Single-value stores to null it breaks everything and gives the following error:

null is not an object (evaluating 'Object.getOwnPropertyDescriptors(obj)')

[ekwoka]

This should be fixable.

I feel like I just looked over this code and it properly checked for nl, but maybe it's a different path.

Null has a type of object so a naive object check would pass it down the wrong path.

[SimoTod]

I think it's the call to initInterceptor in the store file that fails

[anantakrishna]

Moreover, trying to set undefined in Alpine.store(…) doesn't change the value.

[ekwoka]

Because setting it undefined makes the function return the store object instead.

[anantakrishna]

Oh, right. As of now I'm using NaN for the number store. Though would be great to be able to set it to null.

[jay8anks]

I ran into the "undefined" issue, and it's super annoying. I loaded some bad data that set the Alpine.store() value to undefined. Once it's undefined, the only way to access it again was to go through the browser and delete it from local storage.

The Alpine.store initializing the variable never throws an error. It's only when I tried to access it later on that it threw a vague error.

The thought hit me how much it would suck if some bad data ever went out to users and one of the local.storage variables got set to undefined. I would be stuck having to explain to lots of people how to go into their browsers and delete from the local storage, because that's the only solution I could find.

Some way to throw an error if the something doesn't actually get stored in local storage would be super nice.

[ekwoka]

Seems like thats an issue in your code though.

That whatever you have setting it from the storage should not be assuming the values are correct.

How owuld you set it if there was no localstorage? Why would that not be the path to use if the storage was undefined?

[jay8anks]

OK. Here is what I ran into:

document.addEventListener('alpine:initialized', () => { Alpine.store('fuelLogEditId', { fuelLogEditId: Alpine.$persist("0").as('fuelLogEditId'), }); })

Load the page and, in local storage, it sets fuelLogEditId to a value of "0". If that value ever gets set to undefined somehow, reloading the page no longer sets the value to "0". And on top of that, the error you get is super vague. The only error I get is:

JSON.parse: unexpected character at line 1 column 1 of the JSON. That links to the file @alpinejs/[email protected]/dist/cdn.min.js:1

None of the code that persists that value can change it, either. Nor does it throw an error. Now the only way this is getting fixed is to open up developer tools and deleting that key and value. After you do that, everything starts working again.

I do agree that some kind check before storing the value might be a smart thing to do. But, if you also don't know about this issue, it can take a long time to track down.

The only way I could find it was to move code to a test file and start removing code blocks until I found the line that caused the error: JSON.parse: unexpected character at line 1 column 1 of the JSON.

An error message like, "unexpected error persisting fuelLogEditId" would have easily saved me more than a hour of debugging.

I found this thread because someone else had the same problem, too. So, I don't feel too bad.

[ekwoka]

Now the only way this is getting fixed is to open up developer tools and deleting that key and value.

Or just adding

if (localStorage.getItem('fuelLogEditId') === 'undefined') localStorage.removeItem('fuelLogEditId')

I'd really focus on how your code is allowing undefined to ever get set to it, for sure.

But I could see an improvement to Persist doing this check and then just using the initial value.

[jay8anks]

In my case, you click on a table row to load up an edit screen. I accidentally made the query without the id in it. Everything was working just fine until I clicked on a row that didn't have an actual id in it. In actual use, it should never be able to set the value to undefined, because the row will always have an id. But, once it got set to undefined, everything just stopped working very mysteriously. In retrospect, it doesn't seem that difficult a problem. At the time, it was quite hair pulling.

I've been a C# guy for years. This year has been my first real use of Javascript. All I can say is, it's way more picky than C#. I can just about do anything with Alpine.js that I could do with Asp.Net now, but it takes me about 10 to 15 times as long, because Javascript is just flat out harder to debug.

Thanks!

[ekwoka]

I find it pretty simple to debug, especially if you use TypeScript.

[jay8anks]

C# pretty much has TypeScript built in. The difference, for me, is that in almost a decade of C#, I can hardly think of getting an error that I couldn't just search for and find out what I was doing wrong. The only exception to that is, if you don't do async right, it will sometimes eat its errors and fail silently. Javascript can throw some really generic, really vague errors at times. That, and all the packages involved increases where they can happen at. What's built into .Net is pretty solid, and so much is built in you just don't need as many packages. The trade-off to that is that it's really easy to make a web page that looks like it was created in 2008.

…

On Sun, Nov 10, 2024 at 7:08 AM Eric Kwoka ***@***.***> wrote: I find it pretty simple to debug, especially if you use TypeScript. — Reply to this email directly, view it on GitHub <#3204 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AR47IBDTSHZBXLUQ4A6AUD3Z75LFLAVCNFSM6AAAAABRNWW7JWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMRQGQYDINI> . You are receiving this because you commented.Message ID: ***@***.***>

[ekwoka]

Yeah, I try to reduce package dependence, and definitely don't like any that can throw their own errors.

The browser debugger's are pretty simple though to walk through and see what it getting mixed up.