AddScript("~/Script/*.*")

[jayhjkwon]

It would be nice if I could add scripts like this :

ReactSiteConfiguration.Configuration.AddScript("~/scripts/*.*");

Thanks in advance :)

[Daniel15]

The issue with that is resolving dependencies - If you have A.js and B.js and A depends on B, you need to make sure that B is loaded first. There's several solutions to this - Cassette solves it by specifying dependencies (http://getcassette.net/documentation/v2/asset-references), and using JS modules also solves it too.

The option I'm leaning towards is using JS modules. Using a task runner like Gulp to combine everything into a single compiled JS file, and then load the compiled file in ReactJS.NET. I haven't looked too far into this yet though.

[jayhjkwon]

Thanks @Daniel15, I will be using grunt for this.

[jayhjkwon]

Btw, regardless of dependency, it would be still useful if I could use patterns like asp.net bundling does

ReactSiteConfiguration.Configuration
.AddScript("~/scripts/models/*.jsx")
.AddScript("~/scripts/views/*.jsx");

[PeteDuncanson]

I've been playing with getting commonjs modules working (ala node style of writing them) and think I've managed to get it wired up both server-side and client-side.

I've ended up using a Grunt task that stitches together Browserify (where you can do . style of file selections so giving you that for free). You need grunt-react too.

This will generate out a single bundle.js file which has everything in all, grunt-react takes care of compiling the .jsx files into .js and then browserify does the bundling (for bonus points run it through uglify to minify it too).

Then in my React.config I just reference the one bundle.js and I should never really have to revisit it once this is setup.

There are some issues though, when trying to call the components in Razor scripts that I actually want to compile I can't get to them as they are in modules. Best way around that so far is to include a app.js file at the end of the bundle (its just another file to bundle via browserify) which adds a global reference to these top level components. Then things start to work however given what you say here #61 I'm not sure if this "poluting the global namespace" is ok or not as you seem to be saying it might "hang around" between runs. As I'm just using it for storing my root components I'm hoping I'll be ok?

I'll craft up a blog post going into this in a bit more detail this week.

[PeteDuncanson]

I've been playing again. I've been having terrible trouble getting my bundled files down to a sensible size as everything I'm using want to pull in React via the require("react") method in CommonJS. This is really clear when pulling in ReactRouter. By not being able to include re-usable components using require you miss out on so much but by having ReactJS injected by ReactJS.net globally its causing some headaches for me.

I've added a config to my fork of ReactJS which allows you to say "I'm bundling everything up, please don't inject React on my behalf" which seems to make everything a bit easier. Needs testing but I think it might solve alot of my issues with bundling.

[Daniel15]

Thanks for the info :)

. Then things start to work however given what you say here #61 I'm not sure if this "poluting the global namespace" is ok or not as you seem to be saying it might "hang around" between runs. As I'm just using it for storing my root components I'm hoping I'll be ok?

Things that are legitimately global to the app and won't change are fine (so components are okay). In #61 I was talking about per-request data.

I've added a config to my fork of ReactJS which allows you to say "I'm bundling everything up, please don't inject React on my behalf" which seems to make everything a bit easier. Needs testing but I think it might solve alot of my issues with bundling.

Interesting approach, let me know how you go! I'm actually considering testing out Gulp + ReactJS.NET and making the process easier.

[daniellmb]

Are there performance issues with loading everything server-side? Has anyone done performance benchmarks? I want to use ReactJS.NET for progressive enhancement, but I'm concerned about exporting a large jsx codebase server-side. Not only for the reasons mentioned here but it also seems that it wouldn't scale well. Perhaps a modular dependency system based on the current request would help manage the amount of code that is imported/parsed/executed on the server. Thoughts?

[PeteDuncanson]

React.net out the box will use 20 engines but it will only load React once per engine to save on that parsing. After that its just your code that it has to parse and work with each request.

The current set up we have with ReactJS is something like this. We compile everything down to one bundled file which includes all our code, React and React-Router. Basically everything it needs to run. We've had a fork of React.net which disables loading React (as its in our bundle we don't want it twice) and instead we load our whole bundle when each engine initialises. Then the only code we run is the code to get the correct Route from the router. Sadly to work this needs quite a chunk of JSON at the minute which might be a bottle neck but we are working on that.

Once our bundle is loaded though its there in memory ready to be re-used so we save the imported/parsed/executed look on the server. Client-side we send the same bundle down the wire to the client.

Our current bundle is 280K minified and 80K g-zipped. Pretty big but remember thats just about all our site and in browser its blazingly fast and by pre-rendering on the server the user experience is amazingly fast. The time to render on the server is pretty damn quick too. Its just the memory consumption we've noticed thats a worry but we are zero'ing on that and have several tweaks we are working on that should shift it, I don't see it being a problem that we can't fix at this time via some massaging of how ClearScript is being used.

[onethread]

@PeteDuncanson Did you ever write up that blog post? I decided to try the gulp/grunt route as well, and ran into the same issue where Reactjs.net can't see the modules anymore post bundling. Would love to see more details on how you handled that.

[Daniel15]

React.net out the box will use 20 engines but it will only load React once per engine to save on that parsing. After that its just your code that it has to parse and work with each request.

It will actually only load your code once per engine too. Loading a lot of code should only affect the first request that uses that particular engine, requests after the first request should still be very fast. This assumes you're using JavaScript engine pooling (which is turned on by default).

I decided to try the gulp/grunt route as well, and ran into the same issue where Reactjs.net can't see the modules anymore post bundling.

It depends which one of the many many module systems you're using :)

With Webpack, none of the modules are accessible outside of the Webpack bundles, so you need to expose things publicly to use them outside of the Webpack bundle (such as in server-side JavaScript code). One solution is to expose your components publicly, which I've documented at http://reactjs.net/guides/webpack.html. That documentation is for Webpack but Browserify should be similar.

[PeteDuncanson]

@Shadowii I was going to write something but then @Daniel15 beat me to it with is post which cover most of it. Could still write something up though to share the pain. In short Webpack is the way to go :)

[onethread]

@Daniel15 @PeteDuncanson Thanks to both of you for the help, it's putting me on the right track.

Pete, does this mean you switched from Browserify to Webpack? They're both fairly new to me. Before I go and contemplate switching to Webpack, just for the sake of posterity, can you explain how you got it working with Browserify? I used the standalone option, and it does seem to put it into the global var of my choosing, but only the browser seems to see it (React server side does not).

Edit: Well after mucking around with the settings for a few hours, I did get Reactjs.net to see the new namespace server-side, but now it continually throws "Expected identifier, string or number" errors. Throwing in the towel and giving webpack a whirl.

Edit2: After getting webpack working, I went back to browserify just because. Turns out it was an individual module that doesn't seem to like running server side. So now both bundling options work with that module disabled.

[Daniel15]

I'm closing this out since I fixed the initial issue. Feel free to keep discussing Webpack and Browserify elsewhere :D