React.createElement - converting jsx to normal function calls on a large scale










3















How should I convert jsx libraries and elements to normal function calls? Is there any difference between the following two code samples (example simple app component with react-router components is just an example, could be anything, or any element types like 'div', or 'p', or other jsx library):



// normal jsx
const PublicApp = () => (
<Switch>
<Route path="/register" component=Register />
<Route path="/login" component=Login />
<Route path="/about" component=About />
<Redirect to="/login" />
</Switch>
)


// desired api
const PublicApp = () =>
Switch(
,
Route( path: '/register', component: Register ),
Route( path: '/login', component: Login ),
Route( path: '/about', component: About ),
Redirect( to: '/login' )
)


// required helpers
import createElement as h from 'react'
import * as ReactRouter from 'react-router'

export const Switch = (props, ...children) =>
h(ReactRouter.Switch, props, ...children)

export const Route = (props, ...children) =>
h(ReactRouter.Route, props, ...children)

export const Redirect = (props, ...children) =>
h(ReactRouter.Redirect, props, ...children)

export const Div = (props, ...children) => h('div', props, ...children)

. . . .


Both seem to work fine. Any problem with doing this on a large scale? Also, seems sort of silly to have to manually wrap every element type. Is there a better way than using a converter like this:



const converter = el => (props, ...children) => h(el, props, ...children)

export const Switch = converter(ReactRouter.Switch)

export const Route = converter(ReactRouter.Route)

export const Redirect = converter(ReactRouter.Redirect)

export const Div = converter('div')









share|improve this question
























  • If you don’t want to use JSX, why not just call React.createElement(...) directly? And if you want a named function for every element, why not just use JSX?

    – MTCoster
    Nov 16 '18 at 16:05












  • @MTCoster Why not just dump ketchup all over your spaghetti? I mean, it's closer to you than that fine marinara sauce... I'm not a <JSX /> hater, sometimes it results in cleaner looking code. Right now, for whatever reason, I'd just prefer to work with clean javascript and skip all the fancy nonsense.

    – RichardForrester
    Nov 16 '18 at 16:54















3















How should I convert jsx libraries and elements to normal function calls? Is there any difference between the following two code samples (example simple app component with react-router components is just an example, could be anything, or any element types like 'div', or 'p', or other jsx library):



// normal jsx
const PublicApp = () => (
<Switch>
<Route path="/register" component=Register />
<Route path="/login" component=Login />
<Route path="/about" component=About />
<Redirect to="/login" />
</Switch>
)


// desired api
const PublicApp = () =>
Switch(
,
Route( path: '/register', component: Register ),
Route( path: '/login', component: Login ),
Route( path: '/about', component: About ),
Redirect( to: '/login' )
)


// required helpers
import createElement as h from 'react'
import * as ReactRouter from 'react-router'

export const Switch = (props, ...children) =>
h(ReactRouter.Switch, props, ...children)

export const Route = (props, ...children) =>
h(ReactRouter.Route, props, ...children)

export const Redirect = (props, ...children) =>
h(ReactRouter.Redirect, props, ...children)

export const Div = (props, ...children) => h('div', props, ...children)

. . . .


Both seem to work fine. Any problem with doing this on a large scale? Also, seems sort of silly to have to manually wrap every element type. Is there a better way than using a converter like this:



const converter = el => (props, ...children) => h(el, props, ...children)

export const Switch = converter(ReactRouter.Switch)

export const Route = converter(ReactRouter.Route)

export const Redirect = converter(ReactRouter.Redirect)

export const Div = converter('div')









share|improve this question
























  • If you don’t want to use JSX, why not just call React.createElement(...) directly? And if you want a named function for every element, why not just use JSX?

    – MTCoster
    Nov 16 '18 at 16:05












  • @MTCoster Why not just dump ketchup all over your spaghetti? I mean, it's closer to you than that fine marinara sauce... I'm not a <JSX /> hater, sometimes it results in cleaner looking code. Right now, for whatever reason, I'd just prefer to work with clean javascript and skip all the fancy nonsense.

    – RichardForrester
    Nov 16 '18 at 16:54













3












3








3








How should I convert jsx libraries and elements to normal function calls? Is there any difference between the following two code samples (example simple app component with react-router components is just an example, could be anything, or any element types like 'div', or 'p', or other jsx library):



// normal jsx
const PublicApp = () => (
<Switch>
<Route path="/register" component=Register />
<Route path="/login" component=Login />
<Route path="/about" component=About />
<Redirect to="/login" />
</Switch>
)


// desired api
const PublicApp = () =>
Switch(
,
Route( path: '/register', component: Register ),
Route( path: '/login', component: Login ),
Route( path: '/about', component: About ),
Redirect( to: '/login' )
)


// required helpers
import createElement as h from 'react'
import * as ReactRouter from 'react-router'

export const Switch = (props, ...children) =>
h(ReactRouter.Switch, props, ...children)

export const Route = (props, ...children) =>
h(ReactRouter.Route, props, ...children)

export const Redirect = (props, ...children) =>
h(ReactRouter.Redirect, props, ...children)

export const Div = (props, ...children) => h('div', props, ...children)

. . . .


Both seem to work fine. Any problem with doing this on a large scale? Also, seems sort of silly to have to manually wrap every element type. Is there a better way than using a converter like this:



const converter = el => (props, ...children) => h(el, props, ...children)

export const Switch = converter(ReactRouter.Switch)

export const Route = converter(ReactRouter.Route)

export const Redirect = converter(ReactRouter.Redirect)

export const Div = converter('div')









share|improve this question
















How should I convert jsx libraries and elements to normal function calls? Is there any difference between the following two code samples (example simple app component with react-router components is just an example, could be anything, or any element types like 'div', or 'p', or other jsx library):



// normal jsx
const PublicApp = () => (
<Switch>
<Route path="/register" component=Register />
<Route path="/login" component=Login />
<Route path="/about" component=About />
<Redirect to="/login" />
</Switch>
)


// desired api
const PublicApp = () =>
Switch(
,
Route( path: '/register', component: Register ),
Route( path: '/login', component: Login ),
Route( path: '/about', component: About ),
Redirect( to: '/login' )
)


// required helpers
import createElement as h from 'react'
import * as ReactRouter from 'react-router'

export const Switch = (props, ...children) =>
h(ReactRouter.Switch, props, ...children)

export const Route = (props, ...children) =>
h(ReactRouter.Route, props, ...children)

export const Redirect = (props, ...children) =>
h(ReactRouter.Redirect, props, ...children)

export const Div = (props, ...children) => h('div', props, ...children)

. . . .


Both seem to work fine. Any problem with doing this on a large scale? Also, seems sort of silly to have to manually wrap every element type. Is there a better way than using a converter like this:



const converter = el => (props, ...children) => h(el, props, ...children)

export const Switch = converter(ReactRouter.Switch)

export const Route = converter(ReactRouter.Route)

export const Redirect = converter(ReactRouter.Redirect)

export const Div = converter('div')






javascript reactjs






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 16 '18 at 16:02







RichardForrester

















asked Nov 16 '18 at 8:21









RichardForresterRichardForrester

477413




477413












  • If you don’t want to use JSX, why not just call React.createElement(...) directly? And if you want a named function for every element, why not just use JSX?

    – MTCoster
    Nov 16 '18 at 16:05












  • @MTCoster Why not just dump ketchup all over your spaghetti? I mean, it's closer to you than that fine marinara sauce... I'm not a <JSX /> hater, sometimes it results in cleaner looking code. Right now, for whatever reason, I'd just prefer to work with clean javascript and skip all the fancy nonsense.

    – RichardForrester
    Nov 16 '18 at 16:54

















  • If you don’t want to use JSX, why not just call React.createElement(...) directly? And if you want a named function for every element, why not just use JSX?

    – MTCoster
    Nov 16 '18 at 16:05












  • @MTCoster Why not just dump ketchup all over your spaghetti? I mean, it's closer to you than that fine marinara sauce... I'm not a <JSX /> hater, sometimes it results in cleaner looking code. Right now, for whatever reason, I'd just prefer to work with clean javascript and skip all the fancy nonsense.

    – RichardForrester
    Nov 16 '18 at 16:54
















If you don’t want to use JSX, why not just call React.createElement(...) directly? And if you want a named function for every element, why not just use JSX?

– MTCoster
Nov 16 '18 at 16:05






If you don’t want to use JSX, why not just call React.createElement(...) directly? And if you want a named function for every element, why not just use JSX?

– MTCoster
Nov 16 '18 at 16:05














@MTCoster Why not just dump ketchup all over your spaghetti? I mean, it's closer to you than that fine marinara sauce... I'm not a <JSX /> hater, sometimes it results in cleaner looking code. Right now, for whatever reason, I'd just prefer to work with clean javascript and skip all the fancy nonsense.

– RichardForrester
Nov 16 '18 at 16:54





@MTCoster Why not just dump ketchup all over your spaghetti? I mean, it's closer to you than that fine marinara sauce... I'm not a <JSX /> hater, sometimes it results in cleaner looking code. Right now, for whatever reason, I'd just prefer to work with clean javascript and skip all the fancy nonsense.

– RichardForrester
Nov 16 '18 at 16:54












2 Answers
2






active

oldest

votes


















0














I'm not sure this answers your question, because I'm not sure your question even is answerable.



What I think you want is a JavaScript equivalent of e.g. this Reagent (clojurescript React wrapper library) component:



(defn MyComponent [name]
[:div.my-component
[:p.my-component-content
"Hello there "
[:span.my-component-name
:style :color "red"
name]]])


For those not down with the cljs, it's a pure functional React component with a single prop (name) and renders out a div tag with css class 'my-component' that contains a p tag with a span etc. etc. Contrast that with this:



const MyComponent = (name) => (
<div className="my-component">
<p className="my-component-content">
"Hello there " <span className="my-component-name" style="color:red;">name</span>
</p>
</div>
);


Not much difference at first blush except... in the ClojureScript version all of those declarative html bits are first-class regular ClojureScript data structures. You can introspect on them using all of the regular language constructs and tools, because unlike JSX it's not an embedded DSL. You can kinda sorta get this out of JSX by adding refs, but it's not pretty.



Note that the explicit React.createElement version doesn't have this problem, it's objects all the way down and you have references in the lexical scope like you would for any other binding. But you lose declarative-ness: the explicit version is far more verbose (and if you want the benefits you have to use it for everything).



I'm not sure there is a way to have your cake (declarative terseness) and eat it too (first-class language constructs) in JavaScript React. Since Facebook pays some very talented engineers a lot of money to work on this exact problem, and their solution was to embed JSX as a DSL, I'm guessing no. But it would be cool if you could.



One last point on that though.



Be careful about straying too far from the beaten path. If you do something too weird someone else is going come along (maybe even future you) and look at some weird thing you did for the sake of developer ergonomics and say "WTF I can't even read this hot garbage". Innovation happens in that space, but so does a lot of disasters.






share|improve this answer

























  • Thanks, seems I'm in outer-space a lot these days!

    – RichardForrester
    Dec 1 '18 at 20:10











  • @RichardForrester well, "there's got to be a better way to do this crap" is a perfectly rational response to the state of programming in 2018, and "then why hasn't someone already done it?" is a perfectly rational counter-question. :)

    – Jared Smith
    Dec 1 '18 at 20:12



















0














After some searching, it appears that njsx has the best and most well thought out api.



Third-party library components can be individually wrapped in the nsjx default export.



You can even do point-free rendering (tested with ramda.compose):



<Provider store=store>
<PersistGate loading=null persistor=persistor>
<BrowserRouter>
<Route path="/" component=App />
</BrowserRouter>
</PersistGate>
</Provider>


becomes:



compose(
Provider( store ),
PersistGate( loading: null, persistor ),
BrowserRouter,
Route
)( path: '/', component: App )()


From the docs:



No-JSX



A pure function based interface for creating React and React Native components without JSX tags.



If you love React but don't quite like the embeded HTML tags this library may be what you are looking for. Construct your components with code only in a clean, declarative way.



const myView = () =>
div.app(
div.header(
img(src: logo, alt:'logo'),
h2('Welcome to NJSX')
)
)()





share|improve this answer

























    Your Answer






    StackExchange.ifUsing("editor", function ()
    StackExchange.using("externalEditor", function ()
    StackExchange.using("snippets", function ()
    StackExchange.snippets.init();
    );
    );
    , "code-snippets");

    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "1"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader:
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    ,
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );













    draft saved

    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53333936%2freact-createelement-converting-jsx-to-normal-function-calls-on-a-large-scale%23new-answer', 'question_page');

    );

    Post as a guest















    Required, but never shown

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    0














    I'm not sure this answers your question, because I'm not sure your question even is answerable.



    What I think you want is a JavaScript equivalent of e.g. this Reagent (clojurescript React wrapper library) component:



    (defn MyComponent [name]
    [:div.my-component
    [:p.my-component-content
    "Hello there "
    [:span.my-component-name
    :style :color "red"
    name]]])


    For those not down with the cljs, it's a pure functional React component with a single prop (name) and renders out a div tag with css class 'my-component' that contains a p tag with a span etc. etc. Contrast that with this:



    const MyComponent = (name) => (
    <div className="my-component">
    <p className="my-component-content">
    "Hello there " <span className="my-component-name" style="color:red;">name</span>
    </p>
    </div>
    );


    Not much difference at first blush except... in the ClojureScript version all of those declarative html bits are first-class regular ClojureScript data structures. You can introspect on them using all of the regular language constructs and tools, because unlike JSX it's not an embedded DSL. You can kinda sorta get this out of JSX by adding refs, but it's not pretty.



    Note that the explicit React.createElement version doesn't have this problem, it's objects all the way down and you have references in the lexical scope like you would for any other binding. But you lose declarative-ness: the explicit version is far more verbose (and if you want the benefits you have to use it for everything).



    I'm not sure there is a way to have your cake (declarative terseness) and eat it too (first-class language constructs) in JavaScript React. Since Facebook pays some very talented engineers a lot of money to work on this exact problem, and their solution was to embed JSX as a DSL, I'm guessing no. But it would be cool if you could.



    One last point on that though.



    Be careful about straying too far from the beaten path. If you do something too weird someone else is going come along (maybe even future you) and look at some weird thing you did for the sake of developer ergonomics and say "WTF I can't even read this hot garbage". Innovation happens in that space, but so does a lot of disasters.






    share|improve this answer

























    • Thanks, seems I'm in outer-space a lot these days!

      – RichardForrester
      Dec 1 '18 at 20:10











    • @RichardForrester well, "there's got to be a better way to do this crap" is a perfectly rational response to the state of programming in 2018, and "then why hasn't someone already done it?" is a perfectly rational counter-question. :)

      – Jared Smith
      Dec 1 '18 at 20:12
















    0














    I'm not sure this answers your question, because I'm not sure your question even is answerable.



    What I think you want is a JavaScript equivalent of e.g. this Reagent (clojurescript React wrapper library) component:



    (defn MyComponent [name]
    [:div.my-component
    [:p.my-component-content
    "Hello there "
    [:span.my-component-name
    :style :color "red"
    name]]])


    For those not down with the cljs, it's a pure functional React component with a single prop (name) and renders out a div tag with css class 'my-component' that contains a p tag with a span etc. etc. Contrast that with this:



    const MyComponent = (name) => (
    <div className="my-component">
    <p className="my-component-content">
    "Hello there " <span className="my-component-name" style="color:red;">name</span>
    </p>
    </div>
    );


    Not much difference at first blush except... in the ClojureScript version all of those declarative html bits are first-class regular ClojureScript data structures. You can introspect on them using all of the regular language constructs and tools, because unlike JSX it's not an embedded DSL. You can kinda sorta get this out of JSX by adding refs, but it's not pretty.



    Note that the explicit React.createElement version doesn't have this problem, it's objects all the way down and you have references in the lexical scope like you would for any other binding. But you lose declarative-ness: the explicit version is far more verbose (and if you want the benefits you have to use it for everything).



    I'm not sure there is a way to have your cake (declarative terseness) and eat it too (first-class language constructs) in JavaScript React. Since Facebook pays some very talented engineers a lot of money to work on this exact problem, and their solution was to embed JSX as a DSL, I'm guessing no. But it would be cool if you could.



    One last point on that though.



    Be careful about straying too far from the beaten path. If you do something too weird someone else is going come along (maybe even future you) and look at some weird thing you did for the sake of developer ergonomics and say "WTF I can't even read this hot garbage". Innovation happens in that space, but so does a lot of disasters.






    share|improve this answer

























    • Thanks, seems I'm in outer-space a lot these days!

      – RichardForrester
      Dec 1 '18 at 20:10











    • @RichardForrester well, "there's got to be a better way to do this crap" is a perfectly rational response to the state of programming in 2018, and "then why hasn't someone already done it?" is a perfectly rational counter-question. :)

      – Jared Smith
      Dec 1 '18 at 20:12














    0












    0








    0







    I'm not sure this answers your question, because I'm not sure your question even is answerable.



    What I think you want is a JavaScript equivalent of e.g. this Reagent (clojurescript React wrapper library) component:



    (defn MyComponent [name]
    [:div.my-component
    [:p.my-component-content
    "Hello there "
    [:span.my-component-name
    :style :color "red"
    name]]])


    For those not down with the cljs, it's a pure functional React component with a single prop (name) and renders out a div tag with css class 'my-component' that contains a p tag with a span etc. etc. Contrast that with this:



    const MyComponent = (name) => (
    <div className="my-component">
    <p className="my-component-content">
    "Hello there " <span className="my-component-name" style="color:red;">name</span>
    </p>
    </div>
    );


    Not much difference at first blush except... in the ClojureScript version all of those declarative html bits are first-class regular ClojureScript data structures. You can introspect on them using all of the regular language constructs and tools, because unlike JSX it's not an embedded DSL. You can kinda sorta get this out of JSX by adding refs, but it's not pretty.



    Note that the explicit React.createElement version doesn't have this problem, it's objects all the way down and you have references in the lexical scope like you would for any other binding. But you lose declarative-ness: the explicit version is far more verbose (and if you want the benefits you have to use it for everything).



    I'm not sure there is a way to have your cake (declarative terseness) and eat it too (first-class language constructs) in JavaScript React. Since Facebook pays some very talented engineers a lot of money to work on this exact problem, and their solution was to embed JSX as a DSL, I'm guessing no. But it would be cool if you could.



    One last point on that though.



    Be careful about straying too far from the beaten path. If you do something too weird someone else is going come along (maybe even future you) and look at some weird thing you did for the sake of developer ergonomics and say "WTF I can't even read this hot garbage". Innovation happens in that space, but so does a lot of disasters.






    share|improve this answer















    I'm not sure this answers your question, because I'm not sure your question even is answerable.



    What I think you want is a JavaScript equivalent of e.g. this Reagent (clojurescript React wrapper library) component:



    (defn MyComponent [name]
    [:div.my-component
    [:p.my-component-content
    "Hello there "
    [:span.my-component-name
    :style :color "red"
    name]]])


    For those not down with the cljs, it's a pure functional React component with a single prop (name) and renders out a div tag with css class 'my-component' that contains a p tag with a span etc. etc. Contrast that with this:



    const MyComponent = (name) => (
    <div className="my-component">
    <p className="my-component-content">
    "Hello there " <span className="my-component-name" style="color:red;">name</span>
    </p>
    </div>
    );


    Not much difference at first blush except... in the ClojureScript version all of those declarative html bits are first-class regular ClojureScript data structures. You can introspect on them using all of the regular language constructs and tools, because unlike JSX it's not an embedded DSL. You can kinda sorta get this out of JSX by adding refs, but it's not pretty.



    Note that the explicit React.createElement version doesn't have this problem, it's objects all the way down and you have references in the lexical scope like you would for any other binding. But you lose declarative-ness: the explicit version is far more verbose (and if you want the benefits you have to use it for everything).



    I'm not sure there is a way to have your cake (declarative terseness) and eat it too (first-class language constructs) in JavaScript React. Since Facebook pays some very talented engineers a lot of money to work on this exact problem, and their solution was to embed JSX as a DSL, I'm guessing no. But it would be cool if you could.



    One last point on that though.



    Be careful about straying too far from the beaten path. If you do something too weird someone else is going come along (maybe even future you) and look at some weird thing you did for the sake of developer ergonomics and say "WTF I can't even read this hot garbage". Innovation happens in that space, but so does a lot of disasters.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    answered Dec 1 '18 at 20:02


























    community wiki





    Jared Smith













    • Thanks, seems I'm in outer-space a lot these days!

      – RichardForrester
      Dec 1 '18 at 20:10











    • @RichardForrester well, "there's got to be a better way to do this crap" is a perfectly rational response to the state of programming in 2018, and "then why hasn't someone already done it?" is a perfectly rational counter-question. :)

      – Jared Smith
      Dec 1 '18 at 20:12


















    • Thanks, seems I'm in outer-space a lot these days!

      – RichardForrester
      Dec 1 '18 at 20:10











    • @RichardForrester well, "there's got to be a better way to do this crap" is a perfectly rational response to the state of programming in 2018, and "then why hasn't someone already done it?" is a perfectly rational counter-question. :)

      – Jared Smith
      Dec 1 '18 at 20:12

















    Thanks, seems I'm in outer-space a lot these days!

    – RichardForrester
    Dec 1 '18 at 20:10





    Thanks, seems I'm in outer-space a lot these days!

    – RichardForrester
    Dec 1 '18 at 20:10













    @RichardForrester well, "there's got to be a better way to do this crap" is a perfectly rational response to the state of programming in 2018, and "then why hasn't someone already done it?" is a perfectly rational counter-question. :)

    – Jared Smith
    Dec 1 '18 at 20:12






    @RichardForrester well, "there's got to be a better way to do this crap" is a perfectly rational response to the state of programming in 2018, and "then why hasn't someone already done it?" is a perfectly rational counter-question. :)

    – Jared Smith
    Dec 1 '18 at 20:12














    0














    After some searching, it appears that njsx has the best and most well thought out api.



    Third-party library components can be individually wrapped in the nsjx default export.



    You can even do point-free rendering (tested with ramda.compose):



    <Provider store=store>
    <PersistGate loading=null persistor=persistor>
    <BrowserRouter>
    <Route path="/" component=App />
    </BrowserRouter>
    </PersistGate>
    </Provider>


    becomes:



    compose(
    Provider( store ),
    PersistGate( loading: null, persistor ),
    BrowserRouter,
    Route
    )( path: '/', component: App )()


    From the docs:



    No-JSX



    A pure function based interface for creating React and React Native components without JSX tags.



    If you love React but don't quite like the embeded HTML tags this library may be what you are looking for. Construct your components with code only in a clean, declarative way.



    const myView = () =>
    div.app(
    div.header(
    img(src: logo, alt:'logo'),
    h2('Welcome to NJSX')
    )
    )()





    share|improve this answer





























      0














      After some searching, it appears that njsx has the best and most well thought out api.



      Third-party library components can be individually wrapped in the nsjx default export.



      You can even do point-free rendering (tested with ramda.compose):



      <Provider store=store>
      <PersistGate loading=null persistor=persistor>
      <BrowserRouter>
      <Route path="/" component=App />
      </BrowserRouter>
      </PersistGate>
      </Provider>


      becomes:



      compose(
      Provider( store ),
      PersistGate( loading: null, persistor ),
      BrowserRouter,
      Route
      )( path: '/', component: App )()


      From the docs:



      No-JSX



      A pure function based interface for creating React and React Native components without JSX tags.



      If you love React but don't quite like the embeded HTML tags this library may be what you are looking for. Construct your components with code only in a clean, declarative way.



      const myView = () =>
      div.app(
      div.header(
      img(src: logo, alt:'logo'),
      h2('Welcome to NJSX')
      )
      )()





      share|improve this answer



























        0












        0








        0







        After some searching, it appears that njsx has the best and most well thought out api.



        Third-party library components can be individually wrapped in the nsjx default export.



        You can even do point-free rendering (tested with ramda.compose):



        <Provider store=store>
        <PersistGate loading=null persistor=persistor>
        <BrowserRouter>
        <Route path="/" component=App />
        </BrowserRouter>
        </PersistGate>
        </Provider>


        becomes:



        compose(
        Provider( store ),
        PersistGate( loading: null, persistor ),
        BrowserRouter,
        Route
        )( path: '/', component: App )()


        From the docs:



        No-JSX



        A pure function based interface for creating React and React Native components without JSX tags.



        If you love React but don't quite like the embeded HTML tags this library may be what you are looking for. Construct your components with code only in a clean, declarative way.



        const myView = () =>
        div.app(
        div.header(
        img(src: logo, alt:'logo'),
        h2('Welcome to NJSX')
        )
        )()





        share|improve this answer















        After some searching, it appears that njsx has the best and most well thought out api.



        Third-party library components can be individually wrapped in the nsjx default export.



        You can even do point-free rendering (tested with ramda.compose):



        <Provider store=store>
        <PersistGate loading=null persistor=persistor>
        <BrowserRouter>
        <Route path="/" component=App />
        </BrowserRouter>
        </PersistGate>
        </Provider>


        becomes:



        compose(
        Provider( store ),
        PersistGate( loading: null, persistor ),
        BrowserRouter,
        Route
        )( path: '/', component: App )()


        From the docs:



        No-JSX



        A pure function based interface for creating React and React Native components without JSX tags.



        If you love React but don't quite like the embeded HTML tags this library may be what you are looking for. Construct your components with code only in a clean, declarative way.



        const myView = () =>
        div.app(
        div.header(
        img(src: logo, alt:'logo'),
        h2('Welcome to NJSX')
        )
        )()






        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Dec 1 '18 at 20:18

























        answered Dec 1 '18 at 15:24









        RichardForresterRichardForrester

        477413




        477413



























            draft saved

            draft discarded
















































            Thanks for contributing an answer to Stack Overflow!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid


            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.

            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53333936%2freact-createelement-converting-jsx-to-normal-function-calls-on-a-large-scale%23new-answer', 'question_page');

            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Top Tejano songwriter Luis Silva dead of heart attack at 64

            政党

            天津地下鉄3号線