4 ms·

Maybe take a look at the source code for the router component you're so offended by. https://github.com/rackt/react-router/blob/master/modules/components/Route

Maybe take a look at the source code for the router component you're so offended by. https://github.com/rackt/react-router/blob/master/modules/components/Routes.js https://github.com/rackt/react-router/blob/master/modules/co... It doesn't generate any markup itself, but instead renders the component bound to the route. This is a perfectly valid way to communicate how routes are related to components. I'm assuming the React core team liked the approach as well, considering they featured it in one of their community round-up blog posts: http://facebook.github.io/react/blog/2014/08/03/community-roundup-21.html http://facebook.github.io/react/blog/2014/08/03/community-ro...

skrebbel 12y ago
We can agree to disagree right? I think using JSX and React components for configuration is a bad match, and plain JS is a much better and more flexible fit. I also suspect that it is a result of eagerness to use the newly-learned hammer for every nail out there, which is a rather common phenomenon when new technologies quickly rise in popularity. You, on the other hand, think it's neat. That's fine. I don't see how the router's source code is related to this discussion, though. I implied nowhere that that particular router did something bad with rendering markup or something, I'm not sure where you got that from. I'm talking about the API.
- WorldWideWayne 12y ago
  The rationale for using JSX over plain JS is given here - http://facebook.github.io/jsx/ http://facebook.github.io/jsx/ It's not a case of "new hammer", it's being used there for the exact reason JSX was invented - "defining tree structures with attributes" in a standard way since "A generic but well defined syntax enables a community of independent parsers and syntax highlighters to conform to a single specification."
  - skrebbel 12y ago
    > The rationale for using JSX over plain JS is given here Are you pulling my leg or did you simply not read any of the two comments I wrote? My first comment even contained last decade's hype to do "everything in XML" as an example of a similar (bad) movement. Your response is to link to an article that describes JSX as an "XML-like syntax extension to JavaScript". I say "don't do everything in JSX just because you can", and your response is "but it's like XML!". I can only deduct that you also like programming in XML. Good for you, I recommend you begin with porting XSLT to JSX.
    - ebiester 12y ago
      That sounds like a delicious practical joke.
    - WorldWideWayne 12y ago
      No. You didn't say those words that you quoted. You're ranting and raving like a lunatic, so maybe you should just take a minute to think about that. XML is not being used "because they can". First of all - they couldn't use XML inline, which is the reason they invented JSX. Then they could. So, they actually went out of their way to use XML. I didn't link to the article so that you could get a description of JSX, you rude jerk. I linked so you could get the reasoning. Unfortunately, you're being a complete asshole so just like, never-mind I guess. Have a nice day! :) (Oh and - You haven't given one valid reason why you think it's a bad idea. Just rubbish appeals to authority. Your rant contains no logic. What's your reasoning? You asked "Why is it an advantage to express a route as XML-like JSX?" and the answer is in the rationale given on the JSX spec page. There are 1,000 ways to put together a JS object. There is one way to put together XML. It's a better, simpler standard that lends itself to better tooling and simpler parsers that don't need to parse the entire JS language.)
      - efuquen 12y ago
        Your response is way ruder then the OP's, way to escalate the situation ... I don't see how it's hard to understand how using a syntax that was designed for rendering UI components for routing might be a bad idea. It's just screams ugly hack all over the place and I could easily see how it would be confusing and overly verbose.
        WorldWideWayne 12y ago
        XML syntax was not invented for rendering UI components.
- meowface 12y ago
  Just want to say I fully agree with you. react-router seems like a useful library, but I see utterly no reason why you should write your routes in JSX instead of as a simple JS object. Using JSX for anything other than DOM insertion or modification creates an impedance mismatch. The public API makes no real sense to me. The point of JSX is to more easily build dynamic HTML (and perhaps other markup).
  - ryanflorence 12y ago
    Then use them as JavaScript functions, because that's what they are :) The point of JSX is to express attributes and hierarchy, which matches with our route configs perfectly.
  - ryanflorence 12y ago
    If you read the overview you may understand our opinion that "application state" is precisely which views to render. https://github.com/rackt/react-router/blob/master/docs/guides/overview.md https://github.com/rackt/react-router/blob/master/docs/guide... We're almost done with serializing the application data as well. Both pieces are important.
- baddox 12y ago
  > We can agree to disagree right? It's not really agreeing to disagree when you're openly mocking the idea across multiple paragraphs.
  - skrebbel 12y ago
    Your idea of "mocking" strikes me as rather sensitive. I criticized it. I feel like you're telling me that we're not allowed to criticize technical developments on HN and that bothers me. It might just be a cultural divide though. I keep underestimating at how much flower dressing and icing on the cake Americans need in order to be able to deal with criticism. Conversely, you (I'm blatantly assuming you're American) probably think I'm unnecessarily rude.
Touche 12y ago
I'm completely favor of non-UI components but that's not how a client-side router should work. What I mean is tying a particular route to a particular UI component is the wrong way to go. Instead the route should be tied to the application state itself, and application state should be what drives UI.
- vmind 12y ago
  Yes, this seems like a much better approach. I mean, creating components based on path state is completely trivial, once you have state driven by a router, and lets you be explicit about how state is moving around. react-router seems to be taking a more covention over configuration approach (this.props.activeRouteHandler? Really? Why does the top level routing need to specify the deeply nested components? What if there are multiple components in the interface that depend on the route? etc. etc.).
- ryanflorence 12y ago
  We've almost tied all the knots we need to meet this requirement of a router. Every application has UI nesting at the core of its state, though.
  - Touche 12y ago
    The UI is a reflection of the state. UI nesting is not part of the state itself. The route is just a serialized representation of the state.
Kiro 12y ago
If it isn't generating markup then why is it a React component at all?

skrebbel 12y ago

We can agree to disagree right? I think using JSX and React components for configuration is a bad match, and plain JS is a much better and more flexible fit. I also suspect that it is a result of eagerness to use the newly-learned hammer for every nail out there, which is a rather common phenomenon when new technologies quickly rise in popularity. You, on the other hand, think it's neat. That's fine. I don't see how the router's source code is related to this discussion, though. I implied nowhere that that particular router did something bad with rendering markup or something, I'm not sure where you got that from. I'm talking about the API.

WorldWideWayne 12y ago
The rationale for using JSX over plain JS is given here - http://facebook.github.io/jsx/ http://facebook.github.io/jsx/ It's not a case of "new hammer", it's being used there for the exact reason JSX was invented - "defining tree structures with attributes" in a standard way since "A generic but well defined syntax enables a community of independent parsers and syntax highlighters to conform to a single specification."
- skrebbel 12y ago
  > The rationale for using JSX over plain JS is given here Are you pulling my leg or did you simply not read any of the two comments I wrote? My first comment even contained last decade's hype to do "everything in XML" as an example of a similar (bad) movement. Your response is to link to an article that describes JSX as an "XML-like syntax extension to JavaScript". I say "don't do everything in JSX just because you can", and your response is "but it's like XML!". I can only deduct that you also like programming in XML. Good for you, I recommend you begin with porting XSLT to JSX.
  - ebiester 12y ago
    That sounds like a delicious practical joke.
  - WorldWideWayne 12y ago
    No. You didn't say those words that you quoted. You're ranting and raving like a lunatic, so maybe you should just take a minute to think about that. XML is not being used "because they can". First of all - they couldn't use XML inline, which is the reason they invented JSX. Then they could. So, they actually went out of their way to use XML. I didn't link to the article so that you could get a description of JSX, you rude jerk. I linked so you could get the reasoning. Unfortunately, you're being a complete asshole so just like, never-mind I guess. Have a nice day! :) (Oh and - You haven't given one valid reason why you think it's a bad idea. Just rubbish appeals to authority. Your rant contains no logic. What's your reasoning? You asked "Why is it an advantage to express a route as XML-like JSX?" and the answer is in the rationale given on the JSX spec page. There are 1,000 ways to put together a JS object. There is one way to put together XML. It's a better, simpler standard that lends itself to better tooling and simpler parsers that don't need to parse the entire JS language.)
    - efuquen 12y ago
      Your response is way ruder then the OP's, way to escalate the situation ... I don't see how it's hard to understand how using a syntax that was designed for rendering UI components for routing might be a bad idea. It's just screams ugly hack all over the place and I could easily see how it would be confusing and overly verbose.
      - WorldWideWayne 12y ago
        XML syntax was not invented for rendering UI components.
meowface 12y ago
Just want to say I fully agree with you. react-router seems like a useful library, but I see utterly no reason why you should write your routes in JSX instead of as a simple JS object. Using JSX for anything other than DOM insertion or modification creates an impedance mismatch. The public API makes no real sense to me. The point of JSX is to more easily build dynamic HTML (and perhaps other markup).
- ryanflorence 12y ago
  Then use them as JavaScript functions, because that's what they are :) The point of JSX is to express attributes and hierarchy, which matches with our route configs perfectly.
- ryanflorence 12y ago
  If you read the overview you may understand our opinion that "application state" is precisely which views to render. https://github.com/rackt/react-router/blob/master/docs/guides/overview.md https://github.com/rackt/react-router/blob/master/docs/guide... We're almost done with serializing the application data as well. Both pieces are important.
baddox 12y ago
> We can agree to disagree right? It's not really agreeing to disagree when you're openly mocking the idea across multiple paragraphs.
- skrebbel 12y ago
  Your idea of "mocking" strikes me as rather sensitive. I criticized it. I feel like you're telling me that we're not allowed to criticize technical developments on HN and that bothers me. It might just be a cultural divide though. I keep underestimating at how much flower dressing and icing on the cake Americans need in order to be able to deal with criticism. Conversely, you (I'm blatantly assuming you're American) probably think I'm unnecessarily rude.

Touche 12y ago

I'm completely favor of non-UI components but that's not how a client-side router should work. What I mean is tying a particular route to a particular UI component is the wrong way to go. Instead the route should be tied to the application state itself, and application state should be what drives UI.

vmind 12y ago
Yes, this seems like a much better approach. I mean, creating components based on path state is completely trivial, once you have state driven by a router, and lets you be explicit about how state is moving around. react-router seems to be taking a more covention over configuration approach (this.props.activeRouteHandler? Really? Why does the top level routing need to specify the deeply nested components? What if there are multiple components in the interface that depend on the route? etc. etc.).
ryanflorence 12y ago
We've almost tied all the knots we need to meet this requirement of a router. Every application has UI nesting at the core of its state, though.
- Touche 12y ago
  The UI is a reflection of the state. UI nesting is not part of the state itself. The route is just a serialized representation of the state.

Kiro 12y ago

If it isn't generating markup then why is it a React component at all?