Expose routing options to javascript routes

[schmaun]

We needed some options available in our angular application together with the routes configuration. Because we only want one place where routes and their options are defined, we need a way to expose options from the symfony routing definition.

I added a paramater (fos_js_routing.expose_options) to enable this feature. If enabled any exposed_options inside the options of a route are exposed to the javascript routes as a "options" property.

Also I changed the URL from where closure is loaded to githubusercontent.com to get a stable build.

All tests passed: https://travis-ci.org/MyHammer/FOSJsRoutingBundle/builds/114553462

[schmaun]

Is there anything i can do to get this merged? @willdurand

[stof]

Options are meant to configure the route generator and the route matcher only. They are not meant to retrieve data at runtime about the route (doing it in PHP requires using APIs which are not meant for performance, and will be very slow as it will not cache routing info).

So what is the use case for this feature ?

[schmaun]

We are using this bundle to expose our routes to the angular frontend, so it can create URLs on their own. The frontend needs additional information if a specific route is part of the angular single page application or if its a normal route to a page where the backend renders the page.

Our approach was to configure this info (single page or not) together with the routing configuration, so we have only one place where the routes are defined and not an additional place which tells if a route is single-page or not.

This addional option is exposed together with the other routing configuration on dump of the routes to the JS file.

Is a call like 9645296#diff-43d8db7df15e660b384d40030b881e89R123 really a performance issue?

[RobertRajcool]

Add typescript configuration to expose routes

[schmaun]

I'm sorry @Lawrancecool, but I don't understand what you say. Could you explain it a little more in detail?
Anyway.. I'm not sure that my PR will be merged, cause its open quite a while.

[RobertRajcool]

Add typescript configuration to expose routes:
How to generate routes from typescript to call symfony routes.
for example:
Javascript do like that right:
<script src="{{ asset('bundles/fosjsrouting/js/router.js') }}"></script>
<script src="{{ path('fos_js_routing_js', { callback: 'fos.Router.setData' }) }}"></script>
and Expose routes:
Routing.generate('route_name', /* your params */)

How we will do in Typescript??? can you Help

[schmaun]

Sorry. I'm not able to help you. I'm not using Typescript or Angular2. In fact I just wrote this backend stuff for our frontend developer.

[RobertRajcool]

thanks i already got solution

[jaydiablo]

I haven't tried testing this PR, but I think we have a very similar use case that I wanted to explain to see if this helps make the case for adding such a feature.

We're migrating parts of a large application to React + Inertia.js, and we wrote a React component that handles links to routes using the route name and any parameters the route requires. Inside this component we have a list of "Inertia powered routes" so the component knows if it should render a standard a tag with an href (generated by Routing.generate) or if it should use Inertia's InertiaLink. It's not possible to use InertiaLink in all cases, as the app won't return an Inertia friendly response if it's not rendered using the Inertia bundle's render method. And if InertiaLink isn't used at all, then we don't get to take advantage of some of the benefits that Inertia powered navigation brings.

It's not ideal to maintain this list of "Inertia powered routes" in this component, as it's easy for a developer to forget to add the route to the list when a route is migrated to Inertia, or if a route's name is changed, or removed entirely. We thought it would be nice if in the Route's options (via the @Route annotation, or the options: YAML syntax in routes.yaml, similar to how expose is used) we could add something like inertia: true that would then get added to the JSON file that this bundle creates when the routes are dumped. Then, if the JS Routing library could expose a way to retrieve this information from the route, we could use this to decide which link type to render, and that would be synced up pretty well with the route's definition (developers would still need to provide this information in the route's definition, but this way it's at least close to the source, and if a route goes away, changes name or its "inertia status" changes, that's all handled automatically).

I don't understand the performance implications that were mentioned earlier, as, in this case at least, this would only be something that would be called when the JSON file is built (for us that's done during the app's build process, but I'll admit, I don't know how other people are using this library). And unless I'm misunderstanding something, the values here in this "options" property should be static (defined in the Route's annotation, or in the routes.yaml file).

[jaydiablo]

I took @schmaun's branch and merged in the latest master branch, then just tweaked a couple of little things (mainly in the documentation) and have tested this (https://github.com/diablomedia/FOSJsRoutingBundle/tree/expose-options). It works as I'd expect it to (thanks @schmaun for your work on this), and I don't see a performance penalty for the route dump command (but I'm not serving the routes through HTTP).

Docs here: https://github.com/diablomedia/FOSJsRoutingBundle/blob/expose-options/Resources/doc/usage.rst