NewsSite-Next workload is generating keys for <li> element on the fly

[lingyuncai]

Since the data doesn't contain an id field for each item, the workload is now generating keys for each <li> element dynamically while rendering, using uuidv4().

Speedometer/resources/newssite/news-next/src/components/article/article-content.jsx

Lines 23 to 32 in 3150f41

	{content.map((item) =>
	<li key={uuidv4()} className={styles["article-list-item"]}>
	{item.url && !item.title
	? <a href={item.url}>
	<ArticleText text={item.content} />
	</a>
	: <ArticleText text={item.content} />
	}
	</li>
	)}

This will cause keys to never match up between renders, leading to these elements being recreated every time, which defeats the purpose of keys and slows the performance [1].

Besides, this implementation seems inconsistent with that of NewsSite-Nuxt, which uses item.id (which is undefined) as the key binding directly.

Speedometer/resources/newssite/news-nuxt/components/atoms/ArticleContent.vue

Lines 29 to 34 in 3150f41

	<li v-for="item in content" :key="item.id" :class="styles['article-list-item']">
	<a v-if="item.url && !item.title" :href="item.url">
	<ArticleText :text="item.content" />
	</a>
	<ArticleText v-else :text="item.content" />
	</li>

[1] https://react.dev/learn/rendering-lists#rules-of-keys

[lingyuncai]

PR to address this issue: #423

[flashdesignory]

@lingyuncai - thanks for the issue and your solution.
I opened a separate pr, where I added the unique ids to the actual data files.
In that way we don't even need to generate them at any point in the app.

#426

[lingyuncai]

Hi, @flashdesignory

Thanks for your new PRs, they indeed solve this issue in a more clean way and it looks great!

Once these PRs are merged, do you know which version of Speedometer will include these changes?

[flashdesignory]

completed with #447