Implemented Automatic Detection of chip counts and colors # 7 #25
@ -3,7 +3,8 @@ import { ScrollView, Text, Alert, Button } from "react-native";
|
||||
import PlayerSelector from "@/components/PlayerSelector";
|
||||
import BuyInSelector from "@/components/BuyInSelector";
|
||||
import ChipsSelector from "@/components/ChipsSelector";
|
||||
import ChipDistributionSummary from "@/components/ChipDistributionSummary";
|
||||
import ChipDistributionSummary from "@/components/ChipDistributionSummary";
|
||||
import ChipDetection from "@/components/ChipDetection";
|
||||
const IndexScreen = () => {
|
||||
const [playerCount, setPlayerCount] = useState(2);
|
||||
const [buyInAmount, setBuyInAmount] = useState<number | null>(null);
|
||||
@ -29,6 +30,10 @@ const IndexScreen = () => {
|
||||
setPlayerCount={setPlayerCount}
|
||||
/>
|
||||
<BuyInSelector setBuyInAmount={setBuyInAmount} />
|
||||
<ChipDetection
|
||||
totalChipsCount={totalChipsCount}
|
||||
setTotalChipsCount={setTotalChipsCount}
|
||||
/>
|
||||
<ChipsSelector
|
||||
totalChipsCount={totalChipsCount}
|
||||
setTotalChipsCount={setTotalChipsCount}
|
||||
|
||||
47
components/ChipDetection.tsx
Normal file
@ -0,0 +1,47 @@
|
||||
|
|
||||
import React, { useState } from "react";
|
||||
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
import { View, Text } from "react-native";
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
import { MaterialIcons } from "@expo/vector-icons";
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
import * as ImagePicker from "expo-image-picker";
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
/**
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
The best way forward for this component is likely to send the image chosen to an AI + NLP API.
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
Google cloud vision is likely a good choice, as I think it offers some sort of free tier or trial usage for free, as long as it can also support NLP prompts
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
We need to thoughtfully prompt the API and ask it to return data in a well formatted JSON, or return an error if the image supplied is unable to be read, or otherwise out of context
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
We could also ask it to return a "confidence" level as a percentage, if the user may find that helpful
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
*/
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
const ChipDetection = ({
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
totalChipsCount,
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
setTotalChipsCount,
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
}: {
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
totalChipsCount: number[];
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
setTotalChipsCount: React.Dispatch<React.SetStateAction<number[]>>;
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
}) => {
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
const [image, setImage] = useState<any>(null);
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
const pickImage = async () => {
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
const { status } = await ImagePicker.requestMediaLibraryPermissionsAsync();
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
if (status !== "granted") {
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
alert("Permission denied!");
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
return;
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
}
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
const result = await ImagePicker.launchCameraAsync({
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
allowsEditing: true,
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
quality: 1,
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
});
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
if (!result.canceled) {
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
setImage(result.assets[0].uri);
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
}
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
};
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
return (
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
<View>
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
<Text> Automatic Detection</Text>
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
<MaterialIcons name="camera-alt" onPress={pickImage} size={30} />
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
</View>
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
);
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
};
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
export default ChipDetection;
|
||||
|
I think it would be good to make this an You can resolve this comment when done I think it would be good to make this an `env` variable, like the API key.
That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
You can resolve this comment when done Now that we have environment variables using `dotenv`, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion
1. Create and commit a file at the root called `.env.example` This file will might look similar to
```
API_KEY={Put Open AI key here}
GPT_MODEL=gpt-4o-mini
#GPT_MODEL=gpt-4-turbo # More expensive model, use sparingly
```
The purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
2. Update the README.md with a section under the build/run, for how to populate `.env`. Essentially we instruct the developer to copy the `.env.example` with the new name `.env` (`cp .env.example .env`) and to paste their api key.
You can resolve this comment when done
Do you mean the link? Do you mean the link?
|
||||
18
components/__tests__/ChipDetection.test.tsx
Normal file
@ -0,0 +1,18 @@
|
||||
|
I stubbed these tests out before we traded issues, but now would be the time to implement some tests. Tag me for here for another look when done I stubbed these tests out before we traded issues, but now would be the time to implement some tests.
Tag me for here for another look when done
I stubbed these tests out before we traded issues, but now would be the time to implement some tests. Tag me for here for another look when done I stubbed these tests out before we traded issues, but now would be the time to implement some tests.
Tag me for here for another look when done
Sorry, I didn’t notice earlier! I’ll implement the tests now and tag you when they’re ready for review. Sorry, I didn’t notice earlier! I’ll implement the tests now and tag you when they’re ready for review.
Sorry, I didn’t notice earlier! I’ll implement the tests now and tag you when they’re ready for review. Sorry, I didn’t notice earlier! I’ll implement the tests now and tag you when they’re ready for review.
|
||||
import ChipDetection from "@/components/ChipDetection";
|
||||
|
I stubbed these tests out before we traded issues, but now would be the time to implement some tests. Tag me for here for another look when done I stubbed these tests out before we traded issues, but now would be the time to implement some tests.
Tag me for here for another look when done
Sorry, I didn’t notice earlier! I’ll implement the tests now and tag you when they’re ready for review. Sorry, I didn’t notice earlier! I’ll implement the tests now and tag you when they’re ready for review.
|
||||
import { render } from "@testing-library/react-native";
|
||||
|
I stubbed these tests out before we traded issues, but now would be the time to implement some tests. Tag me for here for another look when done I stubbed these tests out before we traded issues, but now would be the time to implement some tests.
Tag me for here for another look when done
Sorry, I didn’t notice earlier! I’ll implement the tests now and tag you when they’re ready for review. Sorry, I didn’t notice earlier! I’ll implement the tests now and tag you when they’re ready for review.
|
||||
import React from "react";
|
||||
|
I stubbed these tests out before we traded issues, but now would be the time to implement some tests. Tag me for here for another look when done I stubbed these tests out before we traded issues, but now would be the time to implement some tests.
Tag me for here for another look when done
Sorry, I didn’t notice earlier! I’ll implement the tests now and tag you when they’re ready for review. Sorry, I didn’t notice earlier! I’ll implement the tests now and tag you when they’re ready for review.
|
||||
|
||||
|
I stubbed these tests out before we traded issues, but now would be the time to implement some tests. Tag me for here for another look when done I stubbed these tests out before we traded issues, but now would be the time to implement some tests.
Tag me for here for another look when done
Sorry, I didn’t notice earlier! I’ll implement the tests now and tag you when they’re ready for review. Sorry, I didn’t notice earlier! I’ll implement the tests now and tag you when they’re ready for review.
|
||||
const totalChipsCount: number[] = [];
|
||||
|
I stubbed these tests out before we traded issues, but now would be the time to implement some tests. Tag me for here for another look when done I stubbed these tests out before we traded issues, but now would be the time to implement some tests.
Tag me for here for another look when done
Sorry, I didn’t notice earlier! I’ll implement the tests now and tag you when they’re ready for review. Sorry, I didn’t notice earlier! I’ll implement the tests now and tag you when they’re ready for review.
|
||||
const mockSetTotalChipsCount = jest.fn();
|
||||
|
I stubbed these tests out before we traded issues, but now would be the time to implement some tests. Tag me for here for another look when done I stubbed these tests out before we traded issues, but now would be the time to implement some tests.
Tag me for here for another look when done
Sorry, I didn’t notice earlier! I’ll implement the tests now and tag you when they’re ready for review. Sorry, I didn’t notice earlier! I’ll implement the tests now and tag you when they’re ready for review.
|
||||
|
||||
|
I stubbed these tests out before we traded issues, but now would be the time to implement some tests. Tag me for here for another look when done I stubbed these tests out before we traded issues, but now would be the time to implement some tests.
Tag me for here for another look when done
Sorry, I didn’t notice earlier! I’ll implement the tests now and tag you when they’re ready for review. Sorry, I didn’t notice earlier! I’ll implement the tests now and tag you when they’re ready for review.
|
||||
const rend = render(
|
||||
|
I stubbed these tests out before we traded issues, but now would be the time to implement some tests. Tag me for here for another look when done I stubbed these tests out before we traded issues, but now would be the time to implement some tests.
Tag me for here for another look when done
Sorry, I didn’t notice earlier! I’ll implement the tests now and tag you when they’re ready for review. Sorry, I didn’t notice earlier! I’ll implement the tests now and tag you when they’re ready for review.
|
||||
<ChipDetection
|
||||
|
I stubbed these tests out before we traded issues, but now would be the time to implement some tests. Tag me for here for another look when done I stubbed these tests out before we traded issues, but now would be the time to implement some tests.
Tag me for here for another look when done
Sorry, I didn’t notice earlier! I’ll implement the tests now and tag you when they’re ready for review. Sorry, I didn’t notice earlier! I’ll implement the tests now and tag you when they’re ready for review.
|
||||
totalChipsCount={totalChipsCount}
|
||||
|
I stubbed these tests out before we traded issues, but now would be the time to implement some tests. Tag me for here for another look when done I stubbed these tests out before we traded issues, but now would be the time to implement some tests.
Tag me for here for another look when done
Sorry, I didn’t notice earlier! I’ll implement the tests now and tag you when they’re ready for review. Sorry, I didn’t notice earlier! I’ll implement the tests now and tag you when they’re ready for review.
|
||||
setTotalChipsCount={mockSetTotalChipsCount}
|
||||
|
I stubbed these tests out before we traded issues, but now would be the time to implement some tests. Tag me for here for another look when done I stubbed these tests out before we traded issues, but now would be the time to implement some tests.
Tag me for here for another look when done
Sorry, I didn’t notice earlier! I’ll implement the tests now and tag you when they’re ready for review. Sorry, I didn’t notice earlier! I’ll implement the tests now and tag you when they’re ready for review.
|
||||
/>
|
||||
|
I stubbed these tests out before we traded issues, but now would be the time to implement some tests. Tag me for here for another look when done I stubbed these tests out before we traded issues, but now would be the time to implement some tests.
Tag me for here for another look when done
Sorry, I didn’t notice earlier! I’ll implement the tests now and tag you when they’re ready for review. Sorry, I didn’t notice earlier! I’ll implement the tests now and tag you when they’re ready for review.
|
||||
);
|
||||
|
I stubbed these tests out before we traded issues, but now would be the time to implement some tests. Tag me for here for another look when done I stubbed these tests out before we traded issues, but now would be the time to implement some tests.
Tag me for here for another look when done
Sorry, I didn’t notice earlier! I’ll implement the tests now and tag you when they’re ready for review. Sorry, I didn’t notice earlier! I’ll implement the tests now and tag you when they’re ready for review.
|
||||
|
||||
|
I stubbed these tests out before we traded issues, but now would be the time to implement some tests. Tag me for here for another look when done I stubbed these tests out before we traded issues, but now would be the time to implement some tests.
Tag me for here for another look when done
Sorry, I didn’t notice earlier! I’ll implement the tests now and tag you when they’re ready for review. Sorry, I didn’t notice earlier! I’ll implement the tests now and tag you when they’re ready for review.
|
||||
describe("tests for ChipDetection", () => {
|
||||
|
I stubbed these tests out before we traded issues, but now would be the time to implement some tests. Tag me for here for another look when done I stubbed these tests out before we traded issues, but now would be the time to implement some tests.
Tag me for here for another look when done
Sorry, I didn’t notice earlier! I’ll implement the tests now and tag you when they’re ready for review. Sorry, I didn’t notice earlier! I’ll implement the tests now and tag you when they’re ready for review.
|
||||
it.todo("first test");
|
||||
|
I stubbed these tests out before we traded issues, but now would be the time to implement some tests. Tag me for here for another look when done I stubbed these tests out before we traded issues, but now would be the time to implement some tests.
Tag me for here for another look when done
Sorry, I didn’t notice earlier! I’ll implement the tests now and tag you when they’re ready for review. Sorry, I didn’t notice earlier! I’ll implement the tests now and tag you when they’re ready for review.
|
||||
it.todo("second test");
|
||||
|
I stubbed these tests out before we traded issues, but now would be the time to implement some tests. Tag me for here for another look when done I stubbed these tests out before we traded issues, but now would be the time to implement some tests.
Tag me for here for another look when done
Sorry, I didn’t notice earlier! I’ll implement the tests now and tag you when they’re ready for review. Sorry, I didn’t notice earlier! I’ll implement the tests now and tag you when they’re ready for review.
|
||||
});
|
||||
|
I stubbed these tests out before we traded issues, but now would be the time to implement some tests. Tag me for here for another look when done I stubbed these tests out before we traded issues, but now would be the time to implement some tests.
Tag me for here for another look when done
Sorry, I didn’t notice earlier! I’ll implement the tests now and tag you when they’re ready for review. Sorry, I didn’t notice earlier! I’ll implement the tests now and tag you when they’re ready for review.
|
||||
@ -38,7 +38,8 @@
|
||||
"react-native-safe-area-context": "4.12.0",
|
||||
"react-native-screens": "~4.4.0",
|
||||
"react-native-web": "~0.19.13",
|
||||
"react-native-webview": "13.12.5"
|
||||
"react-native-webview": "13.12.5",
|
||||
"expo-image-picker": "~16.0.6"
|
||||
},
|
||||
"devDependencies": {
|
||||
"@babel/core": "^7.25.2",
|
||||
|
||||
I think it would be good to make this an
envvariable, like the API key.That way we can change the model on-the-fly easier
You can resolve this comment when done
I think it would be good to make this an
envvariable, like the API key.That way we can change the model on-the-fly easier
You can resolve this comment when done
Now that we have environment variables using
dotenv, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion.env.exampleThis file will might look similar toThe purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
.env. Essentially we instruct the developer to copy the.env.examplewith the new name.env(cp .env.example .env) and to paste their api key.You can resolve this comment when done
Now that we have environment variables using
dotenv, developers need to be aware of this so they can build and run the app locally. Since you may not have done this before, here is my suggestion.env.exampleThis file will might look similar toThe purpose here, is we force the developer to enter their secret key which is not committed, but also make it easy to uncomment/switch models.
.env. Essentially we instruct the developer to copy the.env.examplewith the new name.env(cp .env.example .env) and to paste their api key.You can resolve this comment when done
Do you mean the link?
Do you mean the link?