4 ms·

It might take a moment to familiarize oneself with macros or a DSL, but does that not almost precisely define react component definitions? Surprisingly, the an

by shawn 8y ago

It might take a moment to familiarize oneself with macros or a DSL, but does that not almost precisely define react component definitions? Surprisingly, the answer seems to be no. Experienced react devs rely heavily on metacomponents: components that take other components as input, and return a combined component as output. It's like oldschool template metaprogramming in C++, but you end up merely wanting to stab yourself in the eye with a fork rather than hurl yourself out the nearest office window. A proper macro system would make this pattern unnecessary, because you would rely on macros to generate the specialized components. It would spit out react code that you'd otherwise have to write -- or that you'd have to write a metacomponent for. Note that a metacomponent is not the same as a macro. It's similar, but it still operates at runtime. Here's a rule of thumb. Can your macro system embed the contents of your /etc/passwd file as a string literal into your codebase? If the answer is no, then you're missing out on significant power.

coding123 8y ago
Hopefully etc/password is a bad example? Security issues aside, I feel like reading files that are configuration in nature are best done "at runtime" not compile time. Can you imagine the code that loads a configuration file directly into the code and the ops team unable to reconfigure things? That would be the epitome of "well it worked in MY build".
- TheDong 8y ago
  Note that `/etc/passwd` contains no passwords or other security sensitive stuff. You might be thinking of `/etc/shadow`. That is an example of something you might not actually want to do, though embedding a file from the code repository (e.g. as https://doc.rust-lang.org/std/macro.include_str.html https://doc.rust-lang.org/std/macro.include_str.html does in rust) is a reasonable and common thing to want to do at build time.
- TheDong 8y ago
  I'd also like to reply to the other half of your comment: > Can you imagine the code that loads a configuration file directly into the code and the ops team unable to reconfigure things? Yes! That's what code is, actually! Code is stuff you put in a file which can't be configured easily, but is thus consistent between all deployments of the software. It often actually makes it easier for a problem to be found and reproduced if configuration is baked into the binary vs varying based on the environment the code is run in. In a way, docker images are a means of statically compiling a bunch of random stuff (like /etc/passwd) into your application at build time to remove more environmental variables. Really, loading a configuration file into the binary statically at build time isn't much different from having `const SOME_VARIABLE = "some value"` in your source code... the only difference is how you, the programmer, chose to represent that constant. The line between "configuration" and "code constants" is very thin, so I don't think what you say is a sensible criticism.
kansface 8y ago
> It would spit out react code that you'd otherwise have to write -- or that you'd have to write a metacomponent for. Do you know if anyone is actually doing this? edit: As it turns out, https://github.com/facebook/create-react-app/pull/3675 https://github.com/facebook/create-react-app/pull/3675, yes!

by shawn 8y ago

coding123 8y ago

Hopefully etc/password is a bad example? Security issues aside, I feel like reading files that are configuration in nature are best done "at runtime" not compile time. Can you imagine the code that loads a configuration file directly into the code and the ops team unable to reconfigure things? That would be the epitome of "well it worked in MY build".

TheDong 8y ago
Note that `/etc/passwd` contains no passwords or other security sensitive stuff. You might be thinking of `/etc/shadow`. That is an example of something you might not actually want to do, though embedding a file from the code repository (e.g. as https://doc.rust-lang.org/std/macro.include_str.html https://doc.rust-lang.org/std/macro.include_str.html does in rust) is a reasonable and common thing to want to do at build time.
TheDong 8y ago
I'd also like to reply to the other half of your comment: > Can you imagine the code that loads a configuration file directly into the code and the ops team unable to reconfigure things? Yes! That's what code is, actually! Code is stuff you put in a file which can't be configured easily, but is thus consistent between all deployments of the software. It often actually makes it easier for a problem to be found and reproduced if configuration is baked into the binary vs varying based on the environment the code is run in. In a way, docker images are a means of statically compiling a bunch of random stuff (like /etc/passwd) into your application at build time to remove more environmental variables. Really, loading a configuration file into the binary statically at build time isn't much different from having `const SOME_VARIABLE = "some value"` in your source code... the only difference is how you, the programmer, chose to represent that constant. The line between "configuration" and "code constants" is very thin, so I don't think what you say is a sensible criticism.

kansface 8y ago

> It would spit out react code that you'd otherwise have to write -- or that you'd have to write a metacomponent for. Do you know if anyone is actually doing this? edit: As it turns out, https://github.com/facebook/create-react-app/pull/3675 https://github.com/facebook/create-react-app/pull/3675, yes!