When building software components, you want them to be usable in any situation, and especially inside other web apps. The user of your component should be able to inject the user ID and other app state without side effects, and similarly be able to pull that state out after use.
That’s why, beyond all the standard advice (GRASP SOLID), you’d be wise to avoid tight coupling with PHP Sessions.
PHP’s native1 session is the worst kind of singleton.
It’s accessible everywhere; modifiable by anyone; and, because there’s no way to get the save handlers, there’s no way to safely close an open session, use it for your own purposes, and reopen it with all the original state. Effectively only one system can use it while it’s open.
The Take Home
- Provide an API to allow injecting/requesting user and application state into/from your component.
- Isolate session use in a “state persister” subcomponent that can be swapped out/disabled, ideally at any time during use.
1Shameless plug: I created UserlandSession, as a native session replacement. You can use multiple at the same time, and there’s no global state2 nor visibility. This is not to suggest that you use it in place of native sessions, but it’s available in a pinch or for experimentation.
2Yes, I know cookies and headers are global state. UserlandSession is not meant to solve all your problems, pal.