React is view only library. I really like that it doesn’t try to be a full stack solution. Thanks to that it’s easy to fill the gaps with the library you know and prefer. And routing is one of those gap. In my first react’s app I simply took a look at complementary tools page and chose directorjs for a start. It worked well although very soon I stumbled across few annoying bugs (like not calling route action on init). Workarounds exist but looks like author has no time recently to provide proper fixes. But bugs are not a problem actually. Directorjs simply doesn’t fit conceptually to react. They are two different worlds. So I looked further. The next promising library was react router component. Composable routes in a way one compose react’s comonents was exactly what I was looking for. Unfortunately I have to give up on it because it was a nodejs component and I needed simple and pure javascript solution. And it was too big for my needs. Finally I decided to create my own routing component. Of course it doesn’t have so many features – for example it lacks server side routing (I use scala and spray for that) or server side component rendering but it solves client side routing (for now without supporting html5 history). Sources can be find here: Screenshot from github demo:


And the demo source file:

To initialize router PathInit function must be used. First argument is the main react component instance and the second is a dom node to which rendered component will be attached to. Having done that in App component we can now use <Path/>.

url is a constant attribute that must be passed to the Path to allow it properly analyze the url. It contains previous part of an url that was matched in the parent component and the “next url” that will be parsed in the context of current component (component that Path belongs to). I hope React authors allow in the future to define attributes that are automatically transferred from parent component. That would allow to avoid this boilerplate making Path declaration clearer. Anyway for now url is required to be provided by the user. Second attribute name defines part of the url that must be matched to render component pointed by render attribute. Name don’t distinguish between /clients, clients/ and clients. They are all equivalent. Name can also contains many parts: /clients/new, /clients/under/32 and so on. What’s more interesting it can contains parameters like that:

  • /client/:id
  • /group/:groupName/user/:userId

If such an url is matched, every parameter that was found is passed to the rendered component in it’s props. In the case above id would be accessed by and the gorupName by this.props.groupName.

Path also passes one more parameter in the props of rendered component. It’s a componentUrl and it contains current component’s url. In the combination with an component it can be used to build links in a safe way (that means you won’t need to change urls everywhere if for example one of the parent component’s name will change). In the example it’s used like this:

Sometimes instead of building separate components and passing them as render attribute in many Paths it’s easier to choose what to render directly in one component.

Paths can be replaced with anything (<div> for example). It’s there only because in react you cannot return tags without common parent.

And pretty much that’s all :). I certainly will keep on working on Path component but I think it’s a good start for everyone that would like to develop something similar adjusted to his requirements. The current code is only 196 lines and should be easy to follow. See you.

When I was creating my first application in spray framework I used spray’s directive to serve static content:

As you can see the main actor combines routes from apiRoute (handles all rest requests) and staticRoute (handles static content that is located in src/main/resources/web). Static route returns index.html if no path is provided in the url and any other resource from web directory otherwise). That works pretty well but has three disadvantages:

  • If any file from web directory will change hitting F5 in the browser will return previous content until spray server is restarted. That is very annoying during developing app’s frontend when one wants to see changes immediately.
  • Restarting spray server takes time. Sure it’s relatively not that long (on my machine around 3-4 sec) but still too slow for convenient development process.
  • Returning file content to the user requires JVM involving. Whatever they told you it’s not the best way to do it. And it’s better to save CPU cycles for more important tasks.

I decided to use nginx for that task (it’s small and fast with low memory footprint http server). Here’s my configuration (it’s based on one of the gists but unfortunately I don’t remember the author):

To run nginx I created following script

Notice the -p parameter. Without it nginx looks for provided configuration file (in my example called nginx.conf) in its default configuration directory. What’s interesting on Windows this parameter is not required. I was really surprised with this platform inconsistency.

To stop nginx you must run following command (nginx process it’s not “killable” (at least on windows)):

If everything is ok nginx will start listening on localhost:9000 and from now on it will be responsible for serving files from the web directory. I forgot to mention that I moved web folder outside resources folder to avoid including it in the final jar file.

Spray application is listening on localhost:8080 and all requests coming from localhost:9000/api/* are forwarded there. In my case I use ssl on port 9000 so I had to add following line:

This line transforms https prefix into http one. Of course you can use ssl on spray side as well but it’s unnecessary protection doubling.

And that’s all. Hope that will help someone 🙂

I’ve been working on my form component and here it is: Of course this is still work in progress and it’s missing few essential parts like select tag or better form definition errors handling but I’m already using it in my apps so why not you ;). Below screenshot from example app (from github repo):


Since the last time I made following changes:

  • ref is no longer needed in Submit declaration
  • data property was changed to dataFn. Now it points to this.dataFn (that comes from FormMixin). Unfortunately there is no (known to me) way of making it unnecessary (provided implicitly by Form component). But I can live with that – I hope future versions of react will make it possible.
  • dataFn must be provided in every component (including Form)

This is the code of the form from the screenshot:

For now my form component is strictly connected with semantic ui css framework but I’m working on make it css independent. I hope you’ll find it useful. I’m aware of others similar components but none of them fits my needs. What I was missing the most was inability to freely mix form inputs with form layout. See you soon.