This is regression from #20 .
\Limenius\ReactRenderer\Twig\ReactRenderExtension::__construct() blindly calls \Limenius\ReactRenderer\Renderer\StaticReactRenderer::setRenderer() without checking if the renderer is null. This is an intentionally nullable argument and in certain configurations (e.g. using the bundle with default_rendering: "client_side") will not exist.

Issue

Changes in recent version of react renderer break backwards compatibility with PHP versions 5.x. The composer.json file references a minimum compatibility with PHP 5.5 (

Versions effected

• 5.*
• 4.*

How to recreate

Install package in any version of php5 and follow a normal use case

How we might fix it

• Bump the minimum PHP requirement to 7 in v5
• Remove all changes that caused BC breaks for php 5 in v4

Just opening this issue to let you know that I finally put some time in open sourcing the Silex service provider I made a while ago to use the renderer in my own projects. It's only a single class, but it will help Silex users to use the renderer easily. You can find it here.

I'll add some tests and documentation soon. I'll probably largely copy and adapt the ReactBundle docs if that's okay with you.

Cheers!
BTW, I changed username: tiemevanveen -> teameh 😏

hey i'm modifying the Actual ReactRenderer to allow different data pass in props, the reason of why i change it may not be generic so i ask here if i should make a PR or no if those reason are estimated valuable to make one.

Then, Actually i have modified my app to stop using LocalStorage for keep JsonWebToken between two access of the website. Now i use cookie while logging (i create a Symfony user cookie and i send a JWT token too in response) then on the first call of the app i send the JWT from Php to the APP (SSR) BUT on client side i dont wanted send the JWT, i wanted the app make an API call with the cookie to get back the token.
The main reason is, if i pass the token with props with react on rail (on client-side), i get the same security problem as i wanted dodge by switch from local storage to cookie : any javascript app can check the html data to see the "token" (due to react-on-rail pass data from php to react with a plain html for client side)

in fact, what i have changed for ReactRenderer (only for me, not PR yet that's the reason i ask here for may do one) ? only those part of code :

// ... code before ....
public function reactRenderComponentArray($componentName, array $options = array())
    {
  $clientProps = isset($options['clientProps']) ? $options['clientProps'] : null;
  $serverProps = isset($options['serverProps']) ? $options['serverProps'] : null;
  $clientPropsArray = is_array($clientProps) ? $clientProps : json_decode($clientProps);
  $serverPropsArray = is_array($serverProps) ? $serverProps : json_decode($serverProps);
 //... code again ....
 if ($this->shouldRenderClientSide($options)) {
 //.... kepp all exept change the following line of code
 $clientPropsArray != null ?  json_encode($clientPropsArray)  :  json_encode($data['props'])
}

if ($this->shouldRenderServerSide($options)) {
 //.... kepp all exept change the following line of code
$serverPropsArray != null ? json_encode($serverPropsArray) : json_encode($data['props']),
}

}

this will keep old way (passing only value 'props' for both) working and just let any 'serverProps' or 'clientProps' param override the default 'props' if one or both are set :) mean i can pass a serverProps['token'] and a clientProps without the 'token', as serverProps only used in serverSide, all sensitives data i could pass to it are hided in the DOM created with react-on-rail.

this allow this in twig for exemple

// note that serverProps and clientProps are both set by the controller
{% set app_data = react_component_array(appName, {'serverProps': serverProps, 'clientProps' : clientProps, 'rendering': 'both'}) %}
// ... code for SEO etc ...

// rendering the result without the token in the client HTML (cannot be parsed then)

{{ app_data.componentHtml | raw }}

Thx for reading this and tell me if any PR could be required or if this functionality is too specific to be added to this repo as default

PS : one of the reasons i switched from LocalStorage to Cookie is that post https://dev.to/rdegges/please-stop-using-local-storage-1i04
AND in fact, now i can do a proper SSR with cookie (LocalStorage is only readable from client) without pass the JWT to DOM (that would be on opposite of the solution provided by cookie against localstorage)

I would appreciate a new release for the changes in #48

So we can get rid of these php notices when running on php 8.0

PHP Deprecated:  Required parameter $trace follows optional parameter $registeredStores in vendor/limenius/react-renderer/src/Limenius/ReactRenderer/Renderer/PhpExecJsReactRenderer.php on line 94

There is a possible performance boost. For details, see:

https://github.com/koriym/Koriym.Baracoa#performance-boost

And:

http://stesie.github.io/2016/02/snapshot-performance

It would be great to investigate this further and implement it if it is possible.

Is this library usable without twig/symfony - in a sense of a standalone PHP library? If so, how can that be done?

Thanks!

I'm wondering if it is possible to use this library to perform the React server-side rendering within a standard PHP file without Twig templates? I've spent over a week trying to compile the V8 PHP extension on multiple Ubuntu and CentOS servers and even tried the Docker container with no luck at all, so I've come across this library in search which seems very promising, but I'm looking to use it within a project which just uses standard PHP with no templating engine. Is this possible? I couldn't quite tell from the documentation.

Please see #10

This project seems to be dead as pull requests are not reviewed.

@nacmartin do you still have some time to maintain it?

Hi!
I've configured the bundle to use an external server; when i try to refresh some page in the browser; i got this Invalid or unexpected token in eval() function while the code in the log is
(function() { var reduxProps, context, storeGenerator, store reduxProps = []; context = { "serverSide":true, "location":"\/app_dev.php\/search\/", "scheme":"http", "port":80, "base":"\/app_dev.php","pathname":"\/search\/", "search":null }; storeGenerator = ReactOnRails.getStoreGenerator('opinionStore'); store = storeGenerator(reduxProps, context); ReactOnRails.setStore('opinionStore', store); var props = []; return ReactOnRails.serverRenderReactComponent({ name: 'mainNode', domNodeId: 'sfreact-reactRenderer5b82edaa320b79.31532393', props: props, trace: true, railsContext: { "serverSide":true, "location":"\/app_dev.php\/search\/", "scheme":"http", "port":80, "base":"\/app_dev.php", "pathname":"\/search\/", "search":null }, }); })()

Problem

Release versions for Patch and Minor fix (https://semver.org/) level changes have been made with major BC breaks for Twig versions

Example

Between v5.0.0 and v5.0.1 support for twig version 2 and 1 was dropped. By the looks of things this should have been a Major change given it contained changes that broke any backwards compact with older versions of symfony.

Possible fixes

Given v5.01 + have already been released it will be difficult to maintain any updates between versions given it is unclear if version 5.x.x should maintain twig 2 compatibility so securitiy updates / new feature can be added in to the mainline while the current v5.1+ should be moved to v6. Or the we would want to look to maintain compatibility with twig 2 in the v4 set of releases an keep v5 as is ?

Any thoughts @nacmartin @gempir 🤔

It seems this project is not actively maintained currently.
There are many PRs that are open, awaiting reviews / merges.

@nacmartin if you don't have any time to maintain, would you be open for adding new maintainers?

In our development, we've a mixture of entirely react based frontend with some twig templates for static pages. The Twig templates actually end up including static React components for the header and footer, since it shares the header and footer with the front-end. So we've got a static_template.html.twig file that looks like

<!doctype html>
<!-- index.html - used by webpack-dev-server -->
<html>
<head>
    {% block header %}
        <link href="/assets/styles.css" rel="stylesheet" />
    {% endblock %}
</head>
<body>
    {{  react_component('StaticHeader') }}

    {% block content %}
    {% endblock %}

    {{ react_component('StaticFooter') }}
    <script src="/assets/client.js"></script>
</body>
</html>

I was thinking, for speed improvements, it would be nice to have an option to have these actually rendered statically, where it basically rendered the html in to a twig file as a cache (if said file wasn't there) and rendered from that cached twig in the future. That way we can have static components being rendered from react at even less cost than the (admittedly low) cost of hitting up V8JS with a cached context.

In 2.3.0 (48b98fb#diff-39b69414ad8ca37f14d248ccb3163359), StaticReactRenderer was introduced as a parameter in ReactRenderer… What does this change/do? We now have to pass an AbstractReactRenderer as well as a SaticreactRenderer (which implements AbstractReactRenderer), why not just keep it to one abstract renderer and keep the decision which one to use (Static, PhpExecJs, …) to whoever uses it?

Hi everyone !
Did anyone successfully make it work with Styled-components using server-side rendering ? (e.g: https://www.styled-components.com/docs/advanced#server-side-rendering).

I'm setting my cache on the fly, because depending on the page I want to have a different cache since my JS files are split per page.

So I do $this->reactRenderer->setCache($this->cacheItemPool, $myDynamicKey);

$this-cacheItemPool is the Symfony cache adapter and the dynamic key consists of the page and another id like string. When using this V8JS just seems to crash, but I can't find any more detailed information besides some invalid OPcode messages in the syslog or short message in the php-fpm logs.

Follow up on #3

See https://github.com/shakacode/react_on_rails/pull/345/files#diff-741e57aaaefab9559b7892657ec8c75eL270

Instead of passing the location we should pass a railsContext now. I'm not sure how this would be implemented best. The quickest way would be to pass a context to our function:

{{ react_component('RecipesApp', {'props': props, 'context': context}) }}

But it would be nicer if the user would not have to do this manually.. Any thoughts?

I would be really nice to have data available in our components. Their version is now providing this as the context:

  {
    # URL settings
    href: request.original_url,
    location: "#{uri.path}#{uri.query.present? ? "?#{uri.query}": ""}",
    scheme: uri.scheme, # http
    host: uri.host, # foo.com
    port: uri.port,
    pathname: uri.path, # /posts
    search: uri.query, # id=30&limit=5

    # Other
    serverSide: boolean # Are we being called on the server or client? NOTE, if you conditionally
     # render something different on the server than the client, then React will only show the
     # server version!
  }

I'm already passing the location as a prop to my components now because we don't had this yet.

railsContext should be passed to the store generator as well btw.