Forest header image

Symfony Finland
Random things on PHP, Symfony and web development

How to expose your Routes and Translations to your Front End JavaScript in Symfony

As more and more processing is moving over to the client side you're more likely than ever to need to expose your back end resources via an API. The top of mind is application data, but you'll likely need to get endpoint URLs and translations as well. Or maybe you don't, but you should - manual maintenance is laboursome and error prone.

Even if you're high on the client-side-everything Kool-Aid, you'll need to store your data and supporting resources somewhere. Data (and accomplying binaries) are a natural thing that we developers are used to exposing and accessing, but supporting data like application endpoint routes and translations are often left playing the second fiddle.

The Symfony Full Stack Framework has powerful translation and routing facilities available in the backend. If you're using it for your backend you might as leverage them for your front end as well. Here are a two Symfony bundles that I've used successfully to expose backend resources (other than application data).

By utilising these methods you'll keep your Angular.js, Riot.js, React.js, etc. in sync with your front end code.

Exposing routes to JavaScript in Symfony full stack

The FOSJsRoutingBundle allows you to select routes you want to expose to your Front End application logic. Installation and usage a snap. Go ahead and install the bundle, and then add these to your application template:

<script src="{{ asset('bundles/fosjsrouting/js/router.js') }}">
<script src="{{ path('fos_js_routing_js', {'callback': 'fos.Router.setData'}) }}"></script>

The first script is a router file which allows you to generate backend routes in JavaScript:

Routing.generate('route_id', /* your params */)

The second file contains the actual routes and it is generated automatically. By default it's created dynamically (with a configurable TTL), but you can also dump the translations to a static JavaScript file.

By default the routes are empty, as you need to define the routes you wish to make available. This is done in your routing.ym (app config or bundle) simply set expose to be true in your existing applications:

# app/config/routing.yml
    pattern: /foo/{id}/bar
    defaults: { _controller: HelloBundle:Hello:index }
        expose: true
Once these steps are done you can start using your application routes all over your front end and not worry if for some reason you need to change paths, etc. that they'll break. They'll always be up-to-date.

Read more from the documentation of FOSJsRoutingBundle.

Exposing translations to JavaScript in Symfony full stack

Symfony has a powerful string translation system in the backend. Utilising this same backend is very similar to the one described above for routing. I've successfully used the BazingaJsTranslationBundle to expose translations on multilingual sites.

More specifically I used it with the eZ Platform content management tool which now utilises the Full Stack Symfony application - including the translation services.

To get started, go ahead and install the bundle. Start by inserting the lang attribute to your HTML tag:

<html lang="{{ app.request.locale }}">

Once this is done, add two scripts:

<script src="{{ asset('bundles/bazingajstranslation/js/translator.min.js') }}"></script>
<script src="{{ url('bazinga_jstranslation_js') }}"></script>

As with routing, the first script contains the translation JavaScript helper and the second one the data payload for the current translation. Once again, the payload is dynamic and TTL'ble, but can be dumped as a static file.

The most simple translation method is:


In addition to this basic method the translation bundle holds a lot of commonly required features in localization such as parameters, handling of plural strings and more.

For more details see the BazingaJsTranslationBundle documentation.

Written by Jani Tarvainen on Thursday July 2, 2015
Permalink - Tags: symfony, php, javascript, api, i18n, l10n, php-fpm, ezplatform

« HTTP/2 usage statistics in June 2015 - Migrating Bolt CMS from SQLite to MySQL (MariaDB) »