3 ms·

It's clever. It's well done. I'm not the audience, though. I love React for, you know, "Reactive UI", the "V" of an "MVC" app, but when creating the site's cont

It's clever. It's well done. I'm not the audience, though. I love React for, you know, "Reactive UI", the "V" of an "MVC" app, but when creating the site's content store (the "static API backend") is a "build" time event, I don't feel that there is anything to "react" to.

wtetzner 10y ago
Well, I suspect user interaction is what it would react to.
- spdustin 10y ago
  That's the browser's job. It's the default controller. The model isn't changing state. The controller is translating the same static content over and over. Browsers already do that in "reacting" to user's event inputs, e.g. onclick.
  - atoko 10y ago
    Consider a site with a tabbed navigation bar. With the router you can develop each target page as it's own component and use the url to navigate between them.
    - spdustin 10y ago
      I can appreciate the concept, but Hugo/Jekyll/Middleman can let you author the original "component" pages and automatically generate a nice, simple <nav> element with an unordered list (or ordered list, if it's more semantically correct) of <a> elements. Plus wrap those tab-page components in your site-wide layout "chrome". You could even progressively enhance the site so that the browser uses idle time post-DOMReady to preload linked pages via XMLHttpRequest, so that they can be pre-cached and ready to load when the user clicks the link. No second load required to load the chrome of the site and then load the routed page resource if someone deep-links. My point isn't that React is bad (I really, really dig React for those "reactive" views connected to a model representing dynamic data), but that we're effectively over-engineering an ancient use case — a CMS where content is defined statically at build time — that good ol' HTML does exceedingly well with no complicated tooling and (if marked up and styled sanely, with progressive enhancement where appropriate) no browser compatibility concerns.
    - spdustin 10y ago
      Also: in your case, the model (pages in your site, content in the tabs) isn't changing, the view is, and the built-in capabilities of the browser as the "controller" are sufficient for a static model. Reacting to a user event doesn't mean it's a "reactive UI", every UI is a reactive one by that definition.

wtetzner 10y ago

Well, I suspect user interaction is what it would react to.

spdustin 10y ago
That's the browser's job. It's the default controller. The model isn't changing state. The controller is translating the same static content over and over. Browsers already do that in "reacting" to user's event inputs, e.g. onclick.
- atoko 10y ago
  Consider a site with a tabbed navigation bar. With the router you can develop each target page as it's own component and use the url to navigate between them.
  - spdustin 10y ago
    I can appreciate the concept, but Hugo/Jekyll/Middleman can let you author the original "component" pages and automatically generate a nice, simple <nav> element with an unordered list (or ordered list, if it's more semantically correct) of <a> elements. Plus wrap those tab-page components in your site-wide layout "chrome". You could even progressively enhance the site so that the browser uses idle time post-DOMReady to preload linked pages via XMLHttpRequest, so that they can be pre-cached and ready to load when the user clicks the link. No second load required to load the chrome of the site and then load the routed page resource if someone deep-links. My point isn't that React is bad (I really, really dig React for those "reactive" views connected to a model representing dynamic data), but that we're effectively over-engineering an ancient use case — a CMS where content is defined statically at build time — that good ol' HTML does exceedingly well with no complicated tooling and (if marked up and styled sanely, with progressive enhancement where appropriate) no browser compatibility concerns.
  - spdustin 10y ago
    Also: in your case, the model (pages in your site, content in the tabs) isn't changing, the view is, and the built-in capabilities of the browser as the "controller" are sufficient for a static model. Reacting to a user event doesn't mean it's a "reactive UI", every UI is a reactive one by that definition.