pmb0 / nestjs-tsx-views Goto Github PK

Here is the production build output of my app. The path resolution for @Render isn't working because that path doesn't exist. Do you have recommendations on this?

@pmb0 Does it work with Apollo subscriptions?

@pmb0
Hello, I'm facing an issue while trying to set up nestjs-tsx-views in my project.

• Steps to Reproduce:

1. I installed nestjs-tsx-views using Yarn, and my package.json reflects version "^2.0.0-beta.0".

2. I tried to register the module with the following options:

TsxViewsModule.register({
   viewsDirectory: resolve(__dirname, "./views"),
});

3. When I do this, TypeScript throws the following error:

Argument of type '{ viewsDirectory: string; }' is not assignable to parameter of type 'TsxViewsModuleOptions'.
Object literal may only specify known properties, and 'viewsDirectory' does not exist in type 'TsxViewsModuleOptions'.

• Expected Behavior:
  I expected the module to accept viewsDirectory as a valid option based on the usage in the documentation (if applicable).

• Actual Behavior:
  TypeScript throws an error saying viewsDirectory is not a known property of TsxViewsModuleOptions.

• Additional Information:
  Node version: 18.12.0
  TypeScript version: ^4.9.5

I'd appreciate any guidance on whether I might be doing something incorrectly or if this is an issue with the module itself. Thank you!

Looks like the current versions of React and NestJS are not supported. Any idea when we'll get an update?

Error Log:

npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR! 
npm ERR! While resolving: [app-name]@0.0.17
npm ERR! Found: @nestjs/[email protected]
npm ERR! node_modules/@nestjs/common
npm ERR!   @nestjs/common@"^9.0.0" from the root project
npm ERR! 
npm ERR! Could not resolve dependency:
npm ERR! peer @nestjs/common@"^7.0.0 || ^8.0.0" from [email protected]
npm ERR! node_modules/nestjs-tsx-views
npm ERR!   dev nestjs-tsx-views@"*" from the root project
npm ERR! 
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR! 
npm ERR! See /.npm/eresolve-report.txt for a full report.

npm ERR! A complete log of this run can be found in:
npm ERR!     /.npm/_logs/2022-10-24T05_00_31_629Z-debug-0.log

@pmb0, hi! Thanks for your lib. I believe it is advantageous – I will try to use it.

I have a question – is there some way we could set the component that could be the layout?

I saw earlier in some examples of hbs that it could be set something like this:

app.engine("hbs", expressHbs.engine(
    {
        layoutsDir: "views/layouts", 
        defaultLayout: "layout",
        extname: "hbs"
    }
))

It will be helpful to have this feature inside nestjs-tsx-views.

Also, I think that could be done through the transform property, but just curious about an internal feature.

Any possibility @Render() could be made to take the actual exported TSX view instead of relying on string filename?

Awesome library. Thanks a lot for the work. Feel free to close this :D

I was trying to spin up a demo based on the docs and I ran into the following error:

[Nest] 840  - 01/28/2022, 7:53:31 AM   ERROR [ExceptionsHandler] Cannot read property 'createElement' of undefined
TypeError: Cannot read property 'createElement' of undefined
    at MyView (/home/ritte/workspaces/liftoffjs2/src/views/index.tsx:9:3)

Here is the code I was using:

// views/index.tsx

import React, { ReactElement } from "react";

export interface MyViewProps {
  name: string;
  title: string;
}

const MyView = ({ name, ...props }: MyViewProps): ReactElement => (
  <div>Hello {name}</div>
);

export default MyView;

I converted to this code, and it resolved the error. Note the import.

// views/index.tsx

import * as React from "react";

export interface MyViewProps {
  name: string;
  title: string;
}

const MyView = ({ name, ...props }: MyViewProps): React.ReactElement => (
  <div>Hello {name}</div>
);

export default MyView;

Not sure if there's a change in the React version, or if this is a documentation bug.