Going further
Limitations
Nitro runs your methods in the browser, and that has a few consequences. Server work stays on the server, numbers and regular expressions follow the browser's rules, and a few PHP functions aren't available. None of these ever gives a different result silently.
On this page
Keeping server work in #[Server] methods
Queries, services, Auth, Cache, files, mail and the clock (now(),
date()) all belong to the server. If a browser method uses them, the build fails and tells you
the file and line.
// A browser method: the build fails, because the clock belongs to the server.
public function stamp(): void
{
$this->savedAt = now()->toTimeString();
}
// A #[Server] method runs on the server, where now() is available.
#[Server]
public function stamp(): void
{
$this->savedAt = now()->toTimeString();
}
Creating components with mount()
Only the server can create a component that has a mount() method. It does so on the first
request, on a visit, or during a #[Server] call of the component whose view places it. A change
made only in the browser, such as $set or a browser method, can't place a new one. So a
<nitro:dynamic-component> that switches to such a component needs one of those first.
Numbers, strings and patterns
- Numbers follow JavaScript. Integers are exact up to 253, so
PHP_INT_MAXis 253-1 in the browser. A whole float arrives as an int. Functions such astanhmay differ in the last digit, just as they do between PHP builds. - Strings are UTF-8. Byte functions such as
strlenandsubstrcount bytes, as PHP does. A result that isn't valid UTF-8 appears as U+FFFD. - Regular expressions follow PCRE, translated to JavaScript. Features without an exact equivalent fail with a message: recursion, conditional groups,
\K, backtracking verbs, callouts,(?|, inline modifiers inside the pattern, and duplicate group names. Without the/uflag, patterns match bytes. - Unicode follows the browser. Case mapping and character classes use the browser's Unicode version, which can be older than PHP's.
What isn't available in the browser
- The
$countargument ofpreg_replace(), and the percentage ofsimilar_text() strip_tags()with allowed tagsmb_convert_case()modes other than upper, lower and titleStr::methods that haven't been ported (such asplural,uuidandof), andStr::slugandStr::asciiin languages other thanenhtmlentities()andhtml_entity_decode()withENT_HTML5,ENT_XHTMLorENT_XML1
Using one of these fails the build or fails with a message. They never give a different result from PHP. Call them from a #[Server] method instead.
Teleporting to portals
@teleport targets a named @portal instead of a CSS selector, so the server can
render it too. You can define each @portal only once per page.
Checked in both places
Nitro's own tests run thousands of random methods and views in PHP and, compiled, in the browser, and treat any difference as a bug. What this page lists is what remains different by design.