Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Frameworks #108

Open
tscpp opened this issue Nov 21, 2020 · 3 comments
Open

Frameworks #108

tscpp opened this issue Nov 21, 2020 · 3 comments
Labels
feature New feature or request

Comments

@tscpp
Copy link
Member

tscpp commented Nov 21, 2020

Current behavior
For example, Durandal is installed, and if you are using Durandal with any framework, you need to specify every component and page's view models.

Expected behavior
Maybe if I could specify a framework and send it to KOLint, so it would automatically pull in the expected view model.

@tscpp tscpp added feature New feature or request status: triage and removed status: triage labels Nov 21, 2020
@tscpp tscpp self-assigned this Dec 12, 2020
@maskmaster
Copy link
Contributor

maskmaster commented Dec 19, 2020

Example scenario. I have a view in "app/views/view1.html" and it's corresponding viewmodel in "app/views/view1.ts".

  • I am using requirejs to load the viewmodel, loading it via the module path "viewmodels/view1".
  • I have also set up a corresponding path in tsconfig.json.
  • Durandal uses a convention to find the corresponding view by replacing "viewmodels" with "views" in the module path.

We have a couple of things that complicates matters. Typically in tsconfig we only have paths set up for the ts modules. Therefore, ts have no means to resolve a module id "app/views/view1" for example. The second problem is that modules imported via two different paths are considered to separate modules. Therefore a module id "app/viewmodels/view1" and the same module identified by it's absolute file path, like "/project/src/viewmodels/view1" will be two disctinct modules. We need to be consistent in using logical module paths/ids or file paths. Usually a project will use module paths.

In this case i propose that we use the logical viewmodel id/path in requests to the knockout-lint cli. The cli resolves the module path against TS to it's physical file path. The module path and the resolved physical path are both sent to a callback registered in a kolintrc.js-file where we can create user-provided resolutions (all depending on what framework/library is used, conventions in finding). The user-provided algorithm could use either the physical path or the module path to generate it's view-path. The end result from the user provided hook should be both the "module path" to the HTML file along with the HTML file contents (it could be generated or fetched from completely different places.

The "module path" could be a physical path to the HTML file, or possibly a module id/path that is e.g. resolved by a web browser when locating the HTML file via a sourcemap.

# knockout-lint --viewmodel 'viewmodels/view1 --base .
The CLI uses TS and the tsconfig.json in the current directory '.' to resolve 'viewmodels/view1' to the physical path '/project/src/viewmodels/view1'.

The .kolintrc.js:

...
	framework: (context) => {
		const vm = context.viewmodel;
		if (vm && vm.id.includes('viewmodels/')) {
			context.view.id = 'html!' + vm.id.replace(/viewmodels\//, '/views/');
			const viewPath = vm.filePath.replace(/viewmodels\//, '/views/').replace(/\.ts$/, '.html');
			context.view.content = fs.readFileAsync(viewPath)

will produce the resulting context object

{
  viewmodel: {
    id: 'viewmodels/view1',
    filePath: '/project/src/viewmodels/view1.ts'
  },
  view: {
    id: 'views/view1',
    content: '<content of file /project/src/views/view1.html>'
  }
}

@tscpp tscpp pinned this issue Dec 26, 2020
@tscpp
Copy link
Member Author

tscpp commented Dec 29, 2020

@maskmaster In the case of using the "viewmodel" flag to the cli, should the cli only allow one viewmodel per flag, and should the viewmodel flag be able to be used multiple times?

@tscpp tscpp unpinned this issue May 27, 2021
@tscpp tscpp removed their assignment May 28, 2021
@tscpp
Copy link
Member Author

tscpp commented Jun 4, 2021

A function to handle view models for views could be implemented to the compiler host proposed in #281.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants