PHP ↔ JavaScript communication : constants VS strings - php

Question

I am developping a web-application which makes a heavy use of AJAX. The server often answer by an array in order to concatenate different parts of the response.
I wonder what is the best solution to handle the keys in those arrays among the following two (the JSON encoding and decoding aren't shown):
Strings
This solution is easy to read, especially in JavaScript, but is really brittle and hard to maintain.
PHP :
<?php
return array(
'key_name_1' => 'foo',
'key_name_2' => 'bar'
);
?>
JavaScript :
var result = ajax(...);
alert(result.key_name_1);
Constants
This is a solid solution, which allow for short and numeric keys, but it's heavy and hard to read (use Reflection to automatize the generation of JavaScript constants is not an acceptable solution in my case, and doesn't solve all the drawbacks anyway).
PHP :
<?php
class Answer
{
const CONSTANT_1 = 1;
const CONSTANT_2 = 2;
}
return array(
Answer::CONSTANT_1 => 'foo',
Answer::CONSTANT_2 => 'bar'
);
?>
JavaScript :
Answer.CONSTANT_1 = <?php echo Answer::CONSTANT_1; ?>
Answer.CONSTANT_2 = <?php echo Answer::CONSTANT_2; ?>
var result = ajax(...);
alert(result[Answer.CONSTANT_1]);
According to you, what is the best choice?

Answer 1

I think the string solution is brittle, since any change in key name
must also be perform in the code which use them.
This conclusion is incorrect and will lead to unmaintainable code.
Consider the following PHP data structures:
array(
MyClass::FIELD1 => "my field1 value",
MyClass::FIELD2 => "my field2",
MyClass::FIELD3 => "field 3 is awesome",
);
class MyClass {
const FIELD1 = "field1";
const FIELD2 = "field2";
const FIELD3 = "field3";
}
Assume that we want to use a new field in place of field1 (as in the suggested use case) - we'll call it newfield:
class MyClass {
const FIELD1 = "newfield";
....
}
Now the code is in an inconsistent state. The name of the variable no longer has any correlation to it's value. The FIELD1 constant is essentially lying about the field it represents.
Imagine a new programmer examining this code a year later. She knows newfield exists and wants to access it. But instead of simply typing in result.newfield she has to enter result[Answer.FIELD1]. And every time she wants to access newfield she has the mental overhead of remembering and applying this mapping. But this is a large application with hundreds of fields and most are misdirected in this way. This is brittle and unmaintainable code.
Constants should only be used for values that are constant in nature. The canonical example being storing mathematical constants like pi:
class MyMathClass {
const PI = 3.141592;
}
Constants are one of the worst programming tools available for maintaining a volatile data structure (field names changing on a regular basis).

Answer 2

Once you echo it out JavaScript it will not really be a constant anyway. I would personally use strings if it's going to make your code more readable down the line. Why would this make it brittle and hard to maintain? You could always define a constant string if you need it to be both constant and readable. It's hard to tell without more information if you will be better-served with numbers or words as your keys.