Working with assets (JS, CSS, etc.)

[ishanvyas22]

Currently I'm trying to load a javascript asset from a URL(i.e. asset/main.1270.js), however it doesn't seem to work because response of the request is below:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Server: ReactPHP/1
Date: Fri, 15 Apr 2022 07:49:45 GMT
Content-Length: 378

As you can see the content-type is text/html which is invalid. This should be application/javascript in order for it to work in the browser.

I was wondering if anybody has faced same problem and know how to fix it. Or is there a standard way of doing this?

[clue]

In many real-world use cases, you may want to run X in tandem with an HTTP server or reverse proxy. It is quite common to configure this server to handle access to any static assets and only forward requests to dynamic content to the actual application server. See https://framework-x.org/docs/best-practices/deployment/ for possible configuration options, depending on which web server you use.

That said, you can also handle static assets with X. I'm still working on the docs as handling filesystem access is inherently blocking and requires some special care in long running applications.

In either case, you can always return a response with any appropriate Content-Type. It looks like you may be using the Response::html() helper method in your above snippet. In your case, you may want to return a response like this:

$app->get('/asset/main.1270.js', function () {
    return new Response(
        Response::STATUS_OK,
        ['Content-Type' => 'application/javascript'],
        'alert("works");'
    );
});

I hope this helps 👍

[ishanvyas22]

Hey @clue, thanks for the reply.

I end up doing this:

Create a route specific to assets.

$app->get('/assets/{file:.+}', App\Handlers\AssetHandler::class);

And then using FilesystemHandler to read and return the file content as a response.

class AssetHandler {
    public function __invoke(ServerRequestInterface $request) {
        $fileHandler = new FilesystemHandler(ROOT . DS . 'public' . DS . 'assets');

        $request = $request->withAttribute('path', $request->getAttribute('file'));

        return $fileHandler($request);
    }
}

Is it a right way to do it? Or is there a better way to handle assets using Framework X server?

[clue]

Using the FilesystemHandler is the way to go 👍

Note that this handler is currently under active development and is going to see some major changes as one of the more next major steps. Consider its current usage experimental as long as it's not documented behavior.

In either case, here's an excerpt how I'm using the FilesystemHandler in one of my projects to access files in the public/assets/ folder:

$container = new Container([
    FilesystemHandler::class => fn() => new FilesystemHandler(__DIR__ . '/assets/')
]);

$app = new App($container);

$app->get('/assets/{path}', FilesystemHandler::class);

[pfk84]

In the long run I'd suggest adding a feature to serve static folders containing app assets on endpoints with configurable in-memory caching. On some use cases an infinite cache would certainly be enough as the whole app gets deployed anyways and for all others one could implement something like php-watcher to periodically check for changes and invalidate the cache for that file.

For all the vendor stuff, large images etc. it certainly is recommended to use a cdn, but for app specific files I think this would be a nice addition.

[SimonFrings]

Hey @pfk84

We already started with this topic when we implemented the FilesystemHandler into Framework X. This will be more understandable when we write the documentation for the filesystem chapter, which will also cover file uploading/downloading
and more.

I hope this give some more insights on our plans 👍

[pfk84]

Cool, thanks for the insights! Really looking forward to the updated documentation... :)

[ishanvyas22]

In the long run I'd suggest adding a feature to serve static folders containing app assets on endpoints with configurable in-memory caching. On some use cases an infinite cache would certainly be enough as the whole app gets deployed anyways and for all others one could implement something like php-watcher to periodically check for changes and invalidate the cache for that file.

For all the vendor stuff, large images etc. it certainly is recommended to use a cdn, but for app specific files I think this would be a nice addition.

I agree. When developing an traditional monolith application, this is the common use case for people.