Well...I don't think there's a laravel way of handling this...I don't even think there's an answer to it. It just depends on your application IMO.

I would ask myself a question though. Do I really have that many views that justifies setting a global view variable for all the reqeusts? Even for those requests that do not even touch a single view? What stops me from passing a variable from a controller?

Tying a users basket to their browser session greatly reduces the flexibility of your application and will cause a headache down the line when expansion is needed. For example with a session based cart you can't do retargeting, you can't do reminder emails about a basket and you can't control a basket when the user isn't active, you can't deal with situations in which the information for a product changes and you can't allow users fill their basket on one device and checkout on another. A flexible approach is one in which baskets can be tied to any entity (a user, a session) by storing each basket in the database, then you won't need to deal with handing a basket around the application.

Also with regards to making a basket available to every view, does every view need that information or could you make use of a view composer instead? http://laravel.com/docs/responses#view-composers

thanks for the responses guys. At the moment 90% of my requests touch a view or access the basket in some way.
the backend / admin parts of the site don't but i'm less worried there as an admin user would have an empty session basket so minimal overhead.

It may be more around how my views are organised as I have views based on a master blade template which then include component templates so i get some issues with inheritance and variable scope, so passing the variable around means that I need to add it to many controllers. I did play with using a basecontroller and adding this into the construct function and injecting it into the views that way. But i couldn't really get that to work.

criticsquid: the session basket acts as a cache for logged in users - its also synced back to the database - but not at every change. For users that are not logged in then it is a temporary store so the DB idea seems to cause more problems for than solutions for non-registered users. I'll probably offer a localstorage save later on. Plus, a db query at every request seems likely to be slower and more wasteful than a basic session access - which is using file storage at the moment - this is just a gut feeling.

thanks for the comments

K