Agreed. I even have a great anecdote to illustrate this.
I worked with a team that was split into front and back-end. The team was building an SPA, so the back-end team built out a REST API to compliment the front-end SPA framework. Unfortunately, the API data naming conventions were-designed-like-this.
Those poor front-end developers had to keep switching between dot notation and key notation to access the state props, depending on if it was one word or multiples. A little more insight and understanding into the javascript language would give you the foresight to spare the front-end developers what is essentially a soul crushing way to write javascript.
Agreed. I even have a great anecdote to illustrate this.
I worked with a team that was split into front and back-end. The team was building an SPA, so the back-end team built out a REST API to compliment the front-end SPA framework. Unfortunately, the API data naming conventions were-designed-like-this.
Those poor front-end developers had to keep switching between dot notation and key notation to access the state props, depending on if it was one word or multiples. A little more insight and understanding into the javascript language would give you the foresight to spare the front-end developers what is essentially a soul crushing way to write javascript.
Perhaps a little melodramatic, but still =D
Those on the front-end could use only bracket notation which wouldn't pose any problems for them . Dosen't seem to be much of a problem to me ??
Yeah, it's not really a big problem. Just a good illustration.