Bug: unable to get darkmode class in Vue applications with render function

[Mister-Hope]

I do not think this is expected:

[Mister-Hope]

This should be a bug, but I am not finding the problem is at a glance.

I tried to manually add atk-dark-mode class immedialy after alling Artalk.

And I can see that the artalk div has atk-dark-mode class of a few frames then the class is removed. So it seems that the initialization of Artalk is a async process and artalk will choose to "Replace” the dom. I am not finding a api which seems like "onDOMInitialized" at https://github.com/ArtalkJS/Artalk/blob/d85fc4a71ffdc6b151a5d325d135cc2524894790/docs/develop/event.md so I failed to bypass this issue, so I may need some help here.

[qwqcode]

The backend provides a new feature called useBackendConf that allows the backend API endpoints /api/conf or /api/get (get comment list) to provide configs to the frontend client, allowing the user to control their frontend config through a graphical user interface.

useBackendConf: true (default)

--> user config set in backend
--> when comments list is first loaded (request `/api/get`)
--> config loaded by frontend Artalk client

https://artalk.js.org/guide/backend/fe-control.html

By default, useBackendConf is enabled and it is recommended that the user sets the frontend config in the GUI, as this makes it easier for the user to configure.

---

The backend API provides the config which can then override the frontend darkMode config option when the frontend is first loaded.

(i am considering removing the user's control of the darkMode in the backend in future releases, as this will break the correct configuration of the frontend)

The dark mode state in Artalk Instance can be set by calling setDarkMode after the conf-loaded or list-loaded event has been triggered (i.e., after the client config provided by the backend API has been loaded).

However, the app lifecycle may be a bit confusing due to the constantly evolving development document and version. I apologise for this. 😅

---

We have implemented a tiny component that integrates with Artalk and is used well in our currently published documentation site.

The dark mode feature works well, as far as I can see, and it may be helpful for reference:

Artalk/docs/.vitepress/theme/Artalk.vue

Lines 67 to 80 in 34e59e6

	// dark_mode
	const darkMode = document.querySelector('html').classList.contains('dark')
	artalk.setDarkMode(darkMode)
	// dark_mode 监听
	new MutationObserver((mList) => {
	mList.forEach((m) => {
	if (m.attributeName !== 'class') return
	// @ts-ignore
	const darkMode = m.target.classList.contains('dark')
	artalk.setDarkMode(darkMode)
	})
	}).observe(document.querySelector('html'), { attributes: true })

Related content that may be useful:

Artalk/ui/packages/artalk/src/context.ts

Line 265 in d52b2f5

public setDarkMode(darkMode: boolean): void {

If you have any questions, feel free to reach out to me for further discussion. Thanks!

[Mister-Hope]

Oh I just have another question which is not mentioned in the docs clearly. It seems that artalk does not bypass local envirnoments.

For example, I would like to have artalk not blocked when debuging with vite devserver, and I can bypass by manually add localhost:port such as localhost:8080, however the port may change, and I do perfer to use private ip (e.g.: http://172.26.138.60:8080/) Is there a way for me to do that?

Also, could you please consider bypassing private ip and localhost by default and provide a option for that?

---

Edited: wait, the * are supported specially or the field actually support some syntax like glob or regexp?

[qwqcode]

I plan to use a keys list to restrict the parameters imageUploader, avatarUrl, darkMode and more similar ones to ensure they cannot be altered on the backend and clear documentation should indicate this. Thank you for your response, it is very helpful.

[qwqcode]

Oh I just have another question which is not mentioned in the docs clearly. It seems that artalk does not bypass local envirnoments.

For example, I would like to have artalk not blocked when debuging with vite devserver, and I can bypass by manually add localhost:port such as localhost:8080, however the port may change, and I do perfer to use private ip (e.g.: http://172.26.138.60:8080/) Is there a way for me to do that?

Also, could you please consider bypassing private ip and localhost by default and provide a option for that?

Edited: wait, the * are supported specially or the field actually support some syntax like glob or regexp?

This is a good point, I was thinking if requests from localhost or 127.0.0.1 should be allowed by default. In the development environment, setting trusted_domains¹ to ["*"] will turn off cross-domain checks. Support for regular expressions and wildcards is also a good thing, but it increases the complexity of the program. However, I also hope that this feature is available.

Here is some relevant code:

https://github.com/ArtalkJS/Artalk/blob/master/server/middleware/cors/cors.go
https://github.com/ArtalkJS/Artalk/blob/master/server/middleware/site_origin.go#L88
https://github.com/ArtalkJS/Artalk/blob/master/server/middleware/site_origin_test.go

Footnotes

1. https://artalk.js.org/guide/backend/config.html#%E5%8F%AF%E4%BF%A1%E5%9F%9F%E5%90%8D-trusted-domains ↩

[Mister-Hope]

So do I need to open a new issue as a feature request for this to remind you?

BTW: I am very unfamiliar about go, my tech stack are mainly at js/ts, with dart, java and a litttle cpp.😅

From the line

Artalk/server/middleware/site_origin.go

Lines 97 to 99 in 0b7b6ca

	if utils.ContainsStr(allowURLs, "*") {
	return true, nil // 列表中出现通配符关闭控制
	}

, it seems that you are supporting * specially?

[qwqcode]

So do I need to open a new issue as a feature request for this to remind you?

Yes, a new feature request issue is the way to go. Thanks!

[Mister-Hope]

I still need some help here:

Artalk.ts:88 TypeError: Cannot read properties of undefined (reading 'appendChild')
    at editor (Artalk.es.js:7411:20)
    at Artalk.es.js:7430:7
    at Array.forEach (<anonymous>)
    at _Artalk.initComponents (Artalk.es.js:7427:32)
    at new _Artalk (Artalk.es.js:7397:10)
    at initArtalk (Artalk.ts:73:18)

Artalk is yeilding this, and the line is this.$root.appendChild(editor.$el);

Could you plz check your code to see why this.$root can be lost during initailization?

[qwqcode]

I'm not certain of the specifics of how VuePress works, but my understanding is that switching routes can cause changes to the page data, including elements on the page. If you use Vue's native nextTick along with the listeners established by the router, you may not get the correct data, depending on how the app's lifecycle is implemented.

For instance, Taro framework, which is a higher-level wrapper for Vue3, also has a built-in nextTick that operates differently from Vue's. When switching pages, using Taro's nextTick will have a different outcome compared to using Vue's nextTick, ensuring that the code runs correctly after the page switch.

I don't really understand what magic these frameworks use to optimise performance. 😄 However, after the route switch, some data on the page will be changed, whether it is necessary to use nextTick I think is a matter of the program's own life cycle, the most important thing is to ensure that your data can be correctly obtained.

[qwqcode]

So I am not seeing any need for you to use nextTick, as the div is already there when the component is mounted. And it seems that artalk do not care about any atrribute on it.

Since my comment box component (element) is included in the top-level el that will be updated by the routing switch, I have to use nextTick or setTimeout to make sure I get the element object correctly. I could probably leave the comment box element out of the range of page elements being updated by when the switch is made, and does not use nextTick.

[qwqcode]

So actaully I think that you should only cares about if the api fits spa. Developers should ensure framework not modifying the dom themselves

Thanks for your advice. It got me thinking about compatibility issues and inspired me to do the following. I agree with your suggestion to call the updateConf and reload functions directly in a spa instead of repeatedly creating new instances, as this would reduce the computational overhead and improve performance (although the runtime has a CG). It is true that this is a feature of little use for creating and isolating different instances of Artalk.

[Mister-Hope]

Hi, is there a destory method for Artalk? I believed there are memory leaking in your frontend project, as initializing artalk on the same dom repeatly will cause memory increasing during time.

I believed some listeners or local variables/functions may be "shadowed" when covered by a new instance and they won't be GCed

[qwqcode]

You have reminded me that there may indeed be a memory leak, but I haven't actually verified it.

In my case, I use the el.remove() function to free the dom that artalk is working on, and I use const type declarations to avoid this "shadowing" effect.

Artalk/docs/.vitepress/theme/Artalk.vue

Line 25 in 34e59e6

if (artalkEl) artalkEl.remove()

Artalk/docs/.vitepress/theme/Artalk.vue

Line 43 in 34e59e6

const artalk = new (window as any).Artalk(conf);

This is really a point to ponder, and I'm not quite sure if there are potential places where it's not CGed. (Although I try to only create listeners associated with one dom of artalk rather than lots of event listeners on the window object)

Anyway, repeatedly creating new is not a good choice, especially in spa, and I also prefer to abandon the previous initialisation way (and instantiate the object only once).

Ensuring that it can be effectively CGed requires some finesse, which also creates difficulty in developing programs that don't leak memory. It is easy to make this mistake.

Concerning the scope of the impact: in a spa page, the program's data is saved continuously, but in a static page (such as a hugo blog), the original data is lost every time the page is refreshed, so it is not affected.