How to support NoScript, SEO, PWA & SPA with Vue ?

[rb-ctrl]

Hey,

I am currently gathering ideas and information on how to build a hybrid solution, which will support SEO, NoScript Browsers, but also PWA and even SPA.

---

The base idea is to :

1. generate a static site on the server that renders all initial data (toggle for code and details)

//  Every click function would request a new page from the server at this state
//  in this example there is no such functionallity, but that's the idea, have it functional
//  without JavaScript.

//  data from the server
$dataSet = [
	[
		"count" => "5",
		"text" => "The first Number is five"
	],
	[
		"count" => "11",
		"text" => "The higher you jump..."
	],
	[
		"count" => "0",
		"text" => "...the deeper you fall"
	]
]

//  The part from the HTML that houses the app,
//  but fully filled with all initial data to be displayed in the browser
		<div id="app">
			<h1 v-text="message">Statically rendered</h1>

//  creates 3 blocks from the dataSet above
<?php	foreach ( $dataSet as $data ){	?>
			<component-one
				:counter="<?= $data["count"] ?>"
				text="<?= $data["text"] ?>"
			>
				<div>
					<h3>The Counter is at : <span v-text="counter"><?= $data["count"] ?></span></h3>
					<div>
						<span v-text="text"><?= $data["text"] ?></span>
					</div>
				</div>

			</component-one>
<?php	}	?>
		</div>

//  The template for vue to apply to the "component-one"
		<template id="component-one">
			<div>
				<h3
					@click="clicked"
				>The Counter is at : <span v-text="counter"></span></h3>
				<div>
					<span v-text="text"></span>
				</div>
			</div>
		</template>

2. In the Browser, if JS is enabled, let vue apply itself to the HTML (toggle for code and details

//  Vue is implemented via a self hosted vue.global.js/vue.global.prod.js script
//  if there where some server requesting functionallity, wrap it in JS and prevent its default behavior
//  there is none in this example, but that is the idea to alter the functionallity via JS where it is active

const componentOne = {
//  load the template from the dom and apply it to the component
	template: document.getElementById( 'component-one' ).innerHTML,

	props: {
		counter: {
			type: Number,
			default: 0
		},
		text: {
			type: String,
		}
	},

	setup( props, ctx ){
//  use the prop as the initial value for the counter
		const counter = Vue.ref( props.counter );

//  callback for the @click directive defined in the template
		function clicked(){
//  increment the counter by 1
			counter.value++;
		}

		Vue.onMounted( () => {
//  debug/verify code
			console.log( "one mounted" );
		} );

		return {
			clicked,
			counter
		};
	},
};

const app = Vue.createApp({
	data(){
		return { };
	}
});

app.component( "component-one", componentOne );
app.mount( "#app" );

---

The above works kinda "fine" as long as I am using vue.global.js. The only thing is a warning :

[Vue warn]: Template compilation error: v-text will override element children.

which I understand and belive to be rightfully emitted.
However, as soon as I switch to the vue.global.prod.js, that warning becomes a breaking compile error :

Uncaught SyntaxError: https://vuejs.org/error-reference/#compiler-56

which translates to :

v-text will override element children.

Since this is my intended behavior and I don't think it is that big of a deal, I would have expected the warning to simply disappear in the prod build instead of breaking it.

---

I tried to use

app.config.errorHandler = ( err, instance, info ) => {
	console.log( err, instance, info );
};

but that did nothing in the prod build which makes sense again, because it is for runtime errors and not for compile errors.
In the dev build its warning counterpart actually catches the warning which is a bit strange to me aswell, but I don`t really care about, it's probably to be able to debug better, idk.

app.config.warnHandler = ( err, instance, info ) => {
	console.log( err, instance, info );
};

---

My Question :

1. Is there a workaround/way to supress that error ?
2. Is there a better approach to this ?
3. Is the switch from a warning to a breaking error reasonable ?
4. Is it a bigger deal than I think to override the element children (again, I think the waring in dev is reasonable ) ?
5. Is it generally not reasonable to override existing data ?
   5.1 I thought that it could generally be seen as an update of the existing data, am I wrong ?

I will happily engage in discussion regarding the topic even if that discussion will not help me solve the above described problem.

Please do not tell me that the base idea is stupid without providing reasonable arguments/a starting point for a discussion. Since I am gathering information, I do not yet care about it simply beeing stupid, instead I would just like to expand my knowledge base for possible solution to any kind of usecases in the future and to be able to compare possible solutions to each other.

---

Full source code

<?php
//  index.php
$dataSet = [
	[
		"count" => "5",
		"text" => "The first Number is five"
	],
	[
		"count" => "11",
		"text" => "The higher you jump..."
	],
	[
		"count" => "0",
		"text" => "...the deeper you fall"
	]
]
?>
<!DOCTYPE html>
<html lang="en">
	<head>
		<meta charset="UTF-8">
		<link rel="icon" href="/favicon.ico">
		<meta name="viewport" content="width=device-width, initial-scale=1.0">
		<title>Vue Standalone</title>
	</head>
	<body>
		<div id="app">

<?php	foreach ( $dataSet as $data ){	?>
			<component-one
				:counter="<?= $data["count"] ?>"
				text="<?= $data["text"] ?>"
			>
				<div>
					<h3>The Counter is at : <span v-text="counter"><?= $data["count"] ?></span></h3>
					<div>
						<span v-text="text"><?= $data["text"] ?></span>
					</div>
				</div>
			</component-one>
<?php	}	?>

		</div>

		<template id="component-one">
			<div>
				<h3
					@click="clicked"
				>The Counter is at : <span v-text="counter"></span></h3>
				<div>
					<span v-text="text"></span>
				</div>
			</div>
		</template>

		<script type="text/javascript" src="/js/vue.global.js"></script>
		<script type="text/javascript" src="/js/main.js"></script>
	</body>
</html>

//  main.js
const componentOne = {
	template: document.getElementById( 'component-one' ).innerHTML,

	props: {
		counter: {
			type: Number,
			default: 0
		},
		text: {
			type: String,
		}
	},

	setup( props, ctx ){
		const counter = Vue.ref( props.counter );

		function clicked(){
			counter.value++;
		}

		Vue.onMounted( () => {
			console.log( "one mounted" );
		} );

		return {
			clicked,
			counter
		};
	},
};

const app = Vue.createApp({
	data(){
		return { };
	}
});

//app.config.errorHandler = ( err, instance, info ) => {
	//console.log( err, instance, info );
//};

//app.config.warnHandler = ( err, instance, info ) => {
	//console.log( err, instance, info );
//};

app.component( "component-one", componentOne );
app.mount( "#app" );

vue.global.js
vue.global.prod.js

[StudioKonKon]

I have seemed to run into the same issue after updating from [email protected]. Any version after this gives this error. I wondered if was a bug or intentional but unfortunately it does seem intentional. I am not sure why they've done that as it isn't clearly explained anywhere. The switch from a warning to a breaking error doesn't seem reasonable:

• https://vuejs.org/error-reference/#compiler-56
• https://eslint.vuejs.org/rules/no-child-content

There's only 2 workarounds I have so far. The first is removing contents from [v-text] before mounting:

document.querySelectorAll("[v-text]").forEach((el) => {
   el.textContent = ""
})

app.mount("#app")

---

Otherwise, the other alternative is to make a Custom Directive

<div v-content="text">Default Content</div>

app.directive("content", (el, binding) => {
   el.textContent = binding.value
})

I don't know if there's a better approach, though.

[rb-ctrl]

Maybe this is a better approach

It might be more cumbersome to have an extra element for every part that houses dynamic content, however, it might be a very clean and verbose approach.

I think about an attribute for HTML Tags, maybe something like "dynamic-content" where "false" is what everyone defaults to in its absence, "true" would indicate, that the content is prone to change and "initial" would indicate static content, tho, only to be credible at the beginning and later to be superseded by its counterpart which has "dynamic-content=true" set.

Additional values could be

• tame/slow for content that is changing only very few times or maybe not at all
• agile/rapid for rapidly changing content

---

Examples !!! these are just ideas and have yet to be tested !!!

some kind of ids would be needed to connect them to each other, maybe like with inputs and labels and the for attribute

<component-one
	:counter="<?= $data["count"] ?>"
	text="<?= $data["text"] ?>"
>
	<div>
		<h3>The Counter is at : 
			<span id="unique-1" dynamic-content="initial"><?= $data["count"] ?></span>
			<span for="unique-1" dynamic-content="agile">{{ counter }}</span>
		</h3>
		<div>
			<span id="unique-2" dynamic-content="initial"><?= $data["text"] ?></span>
			<span for="unique-2"  dynamic-content="tame">{{ text }}</span>
		</div>
	</div>

</component-one>

Maybe have a tag, I would have to see how non existing/standard tags affect browser and search engines, but getElementByTagName works on them, so by wrapping the two tags we could maybe switch one of (display: none) and hydrate the other with vue

<component-one
	:counter="<?= $data["count"] ?>"
	text="<?= $data["text"] ?>"
>
	<div>
		<h3>The Counter is at : 
			<dynamic-content>
				<span dynamic-content="initial"><?= $data["count"] ?></span>
				<span dynamic-content="agile">{{ counter }}</span>
			<dynamic-content>
		</h3>
		<div>
			<dynamic-content>
				<span dynamic-content="initial"><?= $data["text"] ?></span>
				<span dynamic-content="tame">{{ text }}</span>
			<dynamic-content>
		</div>
	</div>

</component-one>

of the two i prefer the first one, its more clean and keeps code on the left, where I belive it belongs

---

The benefits of that approach could be :

With that, it would describe itself to programs that crawl the code and store it, wether thats for indexing or archiving or what ever. It would than be possible to inidcate that a certian value is likely to change and the amount of dynamic content a page holds which can be used to categorise websites easier/more precise.
Maybe in times where storing data became such a perverted matter of course, it actually is reasonable to dissallow overwriting data without further description as of why it has been overwritten.