Wasp-lang•5mo ago

How can I get current theme colors and set them to div ?

I want to set background of a div according to the current selected theme. if dark theme is selected then the background should be dark and vice versa so that I can hide the chats visible from div. if you have any suggestion please feel free to suggest me, I am new to frontend dev with tailwind.

 <div className='bottom-0 fixed min-w-[60vw] mt-8 mx-auto py-5 mb-5'>
          <PromptInputForm setMessage={setMessage} messages={messages} />
 </div>

 <div className='bottom-0 fixed min-w-[60vw] mt-8 mx-auto py-5 mb-5'>
          <PromptInputForm setMessage={setMessage} messages={messages} />
 </div>

11 Replies

Filip•5mo ago

Hey @Yashvardhan, this isn't really Wasp-specific so I can't be of much help (I haven't worked a lot with tailwind). I suggest you take a look at their docs for this: https://tailwindcss.com/docs/dark-mode

Dark Mode - Tailwind CSS

Using Tailwind CSS to style your site in dark mode.

Yashvardhan•5mo ago

Thanks @Filip , I have one more thing to ask, here

generateTextToTextResponse

generateTextToTextResponse

is a listed as public api and whenever I hit it with postman it gives 401 because of

if (!context.user) {
    throw new HttpError(401);
  }

if (!context.user) {
    throw new HttpError(401);
  }

so is there any way to use this api out of wasp client without declaring it as api.

Yashvardhan•5mo ago

context.user

context.user

only exists if it is called from client, to expose it I need to use headers for token.

Filip•5mo ago

If I understood the question correctly, you want to call your Action from outside the Wasp app's frontend, as a regular HTTP endpoint?

Yashvardhan•5mo ago

yes, this is what I want

Filip•5mo ago

In that case, yes - you'll have to use the API. Operations (Queries and Actions) are meant to be used as RPCs (i.e,. function calls from the frontend). It is possible to hack your way around and use them from the outside of the app, but that's not what they're meant for and there's no stability guarantee. You can easily avoid repeating the same logic twice by doing something like this:

export const apiFunction = async (..) => {
  // do something
  // call businessLogic function
}

export const actionFunction = async (..) => {
  // do something else
  // call businessLogic function
}

const businessLogic = async (..) => {
  // here's where you put most of your logic to avoid duplication
}

export const apiFunction = async (..) => {
  // do something
  // call businessLogic function
}

export const actionFunction = async (..) => {
  // do something else
  // call businessLogic function
}

const businessLogic = async (..) => {
  // here's where you put most of your logic to avoid duplication
}

Or, if you don't need the Action, you can just implement the API. Finally, you can tell me what exactly you're trying to do (in the bigger picture). Perhaps Wasp has a specialized tool for it and I can help you out.

Yashvardhan•5mo ago

I got your point of keeping business logic separate and call it from API and Operations implementation. Something like this :

api generateTextToTextResponse {
  fn: import { generateTextToTextResponse } from "@src/server/actions.js",
  entities: [User],
  httpRoute: (POST, "/generate-text-to-text-response")
}

action generateTextToTextResponse {
  fn: import { generateTextToTextResponse } from "@src/server/actions.js",
  entities: [User]
}

api generateTextToTextResponse {
  fn: import { generateTextToTextResponse } from "@src/server/actions.js",
  entities: [User],
  httpRoute: (POST, "/generate-text-to-text-response")
}

action generateTextToTextResponse {
  fn: import { generateTextToTextResponse } from "@src/server/actions.js",
  entities: [User]
}

actions.js

export const generateTextToTextResponse: GenerateTextToTextResponse<TextToTextPayload, TextToTextResponse> = async ({ user_prompt }, context) => {
// business logic 
// can be used in wasp client 
// and can also to exposed to http endpoint
}

export const generateTextToTextResponse: GenerateTextToTextResponse<TextToTextPayload, TextToTextResponse> = async ({ user_prompt }, context) => {
// business logic 
// can be used in wasp client 
// and can also to exposed to http endpoint
}

Is it okay If I do this ?

Filip•5mo ago

Hm, not sure if that's going to work, but it's very creative Did you try it out?

Yashvardhan•4mo ago

it works but my problem remains the same, I have to remove

context

context

in order to make it work. @sodic is there any way to check if request is coming from wasp client or any other source.

MEE6•4mo ago

Wohooo @Yashvardhan, you just became a Waspeteer level 1!

Filip•4mo ago

it works but my problem remains the same, I have to remove context in order to make it work.

Understood! If that's a problem, I recommend you take the approach I suggested and properly pass the context to the business logic function yourself. Check out the API docs to better understand the positional arguments it takes: https://wasp-lang.dev/docs/advanced/apis

@sodic is there any way to check if request is coming from wasp client or any other source.

Good question! Wasp doesn't yet offer first-class for doing this, but you can cook it up yourself. There are two ways a requester can inform the server about its identity 1. Request metadata - e.g., user-agent, some other header 2. Request data - e.g., putting a source: "web" | "mobile" field in the payload The 2nd approach works for all requests (RPCs via Queries/Actions, or APIs), but adds noise to your payload. The 1st approach only works when you can set the desired metadata, meaning you have to call your endpoints with the Axios wrapper you import from wasp/client/api Finally, when you're using APIs, you have access to the req object (see the above docs for details), check the Express docs to see what you can find out from that: https://expressjs.com/en/api.html#req

Gaming

Programming

How can I get current theme colors and set them to div ?