feature: view pages

[GamerGirlandCo]

to quote the roadmap:

Special page types which are just Datacore views and which can be put into the side bar or as regular pages.

each view page has its own state consisting of the following properties:

• sourceType: the type of script this view will contain (ex: ts, js, jsx, tsx...)
• script: the actual source code for the script
• title: the title, as displayed in the tab/view header
• currentFile: the configurable path to the current file, so that functions and hooks such as useCurrentPath don't choke

all of these are configurable via the view's settings page, which can be accessed via going into the three-dot menu and clicking "View configuration".

a command to create a view page has also been added to the command palette for ease of use.

as always, let me know if i should add or change anything! :)

[FindingJohnny]

@GamerGirlandCo - did you mean to leave this here? It's a VERY specific version of yarn so I just wanted to be sure. :)

[GamerGirlandCo]

yes, this is to ensure other package managers can't accidentally be used

[FindingJohnny]

Makes sense.

[FindingJohnny]

I'm a big fan of short circuiting patterns when possible. :) I've not verified it, but something like below makes a lot of sense to my brain and helps prevent getting if statments too nested as the code grows.

Suggested change

	if (editorRef.current && !viewRef.current) {
	viewRef.current = new EditorView({
	parent: editorRef.current,
	extensions: [viewContext.app.vault.getConfig("vimMode") && vim()].concat(
	...EDITOR_EXTS.concat(
	...[
	LANG_COMPARTMENT.of(javascript()),
	ViewPlugin.fromClass(
	class {
	constructor(public view: EditorView) {}
	update(update: ViewUpdate) {
	if (update.docChanged) {
	setState({ script: this.view.state.sliceDoc() || "" });
	}
	}
	}
	),
	EDITOR_HL,
	viewContext.app.vault.getConfig("vimMode") && vim(),
	...(viewContext.app.plugins.plugins["datacore-addon-autocomplete"]?.extensions || []),
	].filter((a) => !!a)
	)
	),
	doc: script || "",
	});
	}
	return () => viewRef.current?.destroy();
	if (!editorRef.current || viewRef.current) {
	return () => viewRef.current?.destroy();
	}
	viewRef.current = new EditorView({
	parent: editorRef.current,
	extensions: [viewContext.app.vault.getConfig("vimMode") && vim()].concat(
	...EDITOR_EXTS.concat(
	...[
	LANG_COMPARTMENT.of(javascript()),
	ViewPlugin.fromClass(
	class {
	constructor(public view: EditorView) {}
	update(update: ViewUpdate) {
	if (update.docChanged) {
	setState({ script: this.view.state.sliceDoc() || "" });
	}
	}
	}
	),
	EDITOR_HL,
	viewContext.app.vault.getConfig("vimMode") && vim(),
	...(viewContext.app.plugins.plugins["datacore-addon-autocomplete"]?.extensions || []),
	].filter((a) => !!a)
	)
	),
	doc: script || "",
	});
	return () => viewRef.current?.destroy();

[GamerGirlandCo]

why are you returning the useEffect cleanup early?

[FindingJohnny]

I could be missing a nuance for how useEffect clean up functions work, but my main goal here was to early exit or short circuit the if statement. Since the current function always returned the clean up code, I wanted my modified suggestion also to return it. This article does a pretty good job describing it: https://medium.com/swlh/return-early-pattern-3d18a41bba8

Arguably since there is only one if statement, it might not be truly necessary yet, but I like to start the pattern early so that you don't end up with a bunch of nested if statements as the code base invariably grows. But some people might argue that's over engineering. Just thought I'd bring it up for discussion. 🙂

Please of course feel free to reject the suggestion if it seems like overkill to you or my thinking is flawed. 🙂

[FindingJohnny]

Suggested change

	{ label: "Typescript JSX", value: "tsx" },
	{ label: "Typescript TSX", value: "tsx" },