Decimal number issue from server to client. Wow! Didn't expect this @_@

-

Chapter 17 where a poor Decimal Number came from Server Side to JavaScript

I worked on a page for days, adjusting the UI with CSS and HTML. Everything looked fine… until I started testing multi-lingual support.

English — OK. Spanish — OK. Chinese — OK. Even right-to-left Hebrew (crooked and askew, but working).

But Russian? Nope. In Russian the page stopped working completely: only static texts and images were visible. Nothing dynamic rendered.

Of course it was a JavaScript error. Firefox DevTools showed this:

That error led me to this JS code:

I stared at those lines and saw nothing wrong — no missing variables, no typos, nothing obvious.

I went to the original project code to find the exact non-rendered rows and noticed a server variable embedded into the client-side script:

Which naturally led me to the server-side C# code responsible for generating that value:

Nothing looked wrong there either.

So I did what every developer does in moments like this: re-run the page again and again, stare at logs, stare at code, stare at the same lines in different windows… for another 10–15 minutes. :-\

The Breakthrough

Then I decided to run the page in Chrome (remember, the entire saga was happening in Firefox).

And Chrome showed the error:

It pointed me directly to the highlighted line:

Ah, such familiar lines…

Wait. What?

"Unexpected number"… in that line…

Firefox, why didn’t you tell me this?

And then it became painfully obvious.

A comma instead of a period.

Decimal formatting on the server side (culture-specific) produced a value like 12,34, which JavaScript interpreted as an invalid numeric literal.

F*ing globalization formatting.

The Fix

The story ended in one minute with this change:


Another long story that was supposed to be short… :-\

Comments

Post a Comment

Popular posts from this blog

Shrinking node_modules for AWS Lambda (My First “npm shock” and a Practical Fix)

-
Image
I’m a newbie in Node.js and not really familiar with the whole npm ecosystem. I honestly didn’t expect that a single npm install would explode into ~10MB spread across ~30 different folders. After a few minutes of staring at it, I realized what’s actually inside those folders: not just runtime code. What shocked me Inside node_modules you get everything: README files source files tests examples docs And then the next level of madness: modules inside modules . Duplicated dependencies nested multiple levels deep (e.g. inherits , core-util-is , tedious …), even if they already exist elsewhere in the project tree. Here’s a typical example: I’m in node_modules → package bl , and there’s another node_modules folder inside it, plus test , README and other “junk”… all for a ~10KB JS file. The obvious assumption (that turned out wrong) Once I accepted the chaos, I assumed there must be a “build for production” command that would “compile” depende...
Read more