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>
No description
11 Replies
Filip
Filip3mo 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
Yashvardhan3mo 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.
No description
No description
Yashvardhan
Yashvardhan3mo ago
context.user
context.user
only exists if it is called from client, to expose it I need to use headers for token.
Filip
Filip3mo 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
Yashvardhan3mo ago
yes, this is what I want
Filip
Filip3mo 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
Yashvardhan3mo 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
Filip3mo ago
Hm, not sure if that's going to work, but it's very creative Did you try it out?
Yashvardhan
Yashvardhan3mo 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.
No description
MEE6
MEE63mo ago
Wohooo @Yashvardhan, you just became a Waspeteer level 1!
Filip
Filip3mo 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