Enhancement: Custom Market Resolution Labels with Emoji Support#522
Enhancement: Custom Market Resolution Labels with Emoji Support#522
Conversation
| onChange(syntheticEvent); | ||
|
|
||
| // Update cursor position and focus back to input | ||
| setTimeout(() => { |
There was a problem hiding this comment.
This is where me not being a react/frontend developer becomes a problem, I wonder if there is a library for this type of thing?
There was a problem hiding this comment.
@raisch ... the above being said, maybe we should have a sort of, "phase two," project to just hire a real react frontend developer specialist at some point to kind of refactor and improve a bunch of stuff overall for us and decrease our footprint?
Of course this might be more of a nice to have rather than need to have. I have approved the MR so we can get all of this in here. I have not tested but assume it all works.
We could merge to main if you're confident it works and then we can deploy main to brierfoxforecast.com, demo, then we can tag it with a new version once it works there without issue.
This will be a breaking change so we would push to v1.0.0
pwdel
left a comment
pwdel
left a comment
There was a problem hiding this comment.
migration/ ... I believe, for the purposes of upgrading from 0.X.X to 1.X.X we will need a migration to be in place.
updated docker-compose-dev.yaml with new images so that local instances build properly
I get this out of the docker logs (specifically the backend) when trying to work out why I keep getting NS_ERR_NET_RESET AND NS_ERROR_CONNECTION_REFUSED
|
|
I like the idea of providing demo data and the option for the user to use that data for evaluation or whatever reason they want. But I don't like the idea of creating so many files in the scripts directory. I would prefer an approach where the .sql file and the golang code be included in the backend code. This way all the required code and files will be bundled inside the backend container and the end user can simply run a command like: A way to remove these data should be nice as well. |
I second that we need a migration - the automigrate isn't working properly on |
It's possible that @astrosnat has some other issue relating to the local .env, she's going to try to work through that. But that being said, if automigrate doesn't work on the market model, then we might want to explicitly create a specific migration that will help migrate from v0.0.7 to v1.0.0 ... she's going to get back to us when she works on this tomorrow. re: #522 (comment) FYI @raisch |
|
I did find some stray postgres images that were about 8 months old, and I just deleted them. I'm going to do a clean install of this branch now and see what happens. |
|
We are still in version v0.x.z . That means we are still in development process. So each pull request/fix/update/new-release/etc should be treated as a clean, new install. It's code update has the potential of breaking changes, so each new code should be treated as a clean install. |
Yes, I generally completely nuke my old install before I test out a PR, and I thought I did that but forgot to clear up an old stray image. Lesson learned 
Now I get this instead |
|
Also these logs come from 2025-10-10 18:37:18.534 | /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration |
|
Are you deploying prod or dev? |
Dev version |
|
The .env file is missing the API_URL entry. #530 is attempting to fix that, along with some other changes. |
Thanks so much, will try |
|
@ntoufoudis yes once I merged #530 into here it worked :) thank you so much @raisch now I'm going to take a full and proper look now that I can actually run a local instance |
|
Tested locally after refactor. Did not add timestamped migration. 
Seems to work fine with autoupdate. However I may not have pulled from a previous database, in which case we could create a specific timestamped for this feature if we run into a problem. So basically, timestamped migration is optional at this point. 
|
|
Had to do some devops changes here. Tested on dev mode, not local. dev was pulling from ghcr. local was pulling from the local image. Attempted to switch these around. |
|
Fixed "Show" button. 
|
|
Double checked localhost based upon my changes. Localhost pulls from ghcr, not locally built images, and works. Dev changes not reflecting on local (presume because no code mount). My understanding is that local is meant to be static, not a "dev/local" thing with mounted code. 
|
| # Strip quotes from values | ||
| line=$(echo "$line" | sed "s/='\([^']*\)'/=\1/g" | sed 's/="\([^"]*\)"/=\1/g') |
There was a problem hiding this comment.
Stripping quotes from values can have unexpected behavior depending on the value the variable is holding. If it includes special characters, etc.
Why go this approach?
There was a problem hiding this comment.
Hm. Hadn't considered that. Then again, it's been a long time since I had to write bash scripts. ;-)
The problem here is that without striping quotes you can end up with export foo=''bar'' (double single quotes) which would be BAD™ :-)
Perhaps it might be better to parse out {$NAME}={$VALUE}, strip quotes from value and then export $NAME="$VALUE"?
Thoughts?
| # Function to load .env file | ||
| load_env() { | ||
| local env_file="${1:-.env}" | ||
|
|
||
| if [ -f "$env_file" ]; then | ||
| print_status "Loading configuration from $env_file" | ||
|
|
||
| # Export variables from .env file, ignoring comments and empty lines | ||
| # Use a safer approach that handles special characters and comments | ||
| while IFS= read -r line; do | ||
| # Skip empty lines and comments | ||
| if [[ -z "$line" || "$line" =~ ^[[:space:]]*# ]]; then | ||
| continue | ||
| fi | ||
|
|
||
| # Export the variable if it contains an equals sign | ||
| if [[ "$line" =~ = ]]; then | ||
| # Strip quotes from values | ||
| line=$(echo "$line" | sed "s/='\([^']*\)'/=\1/g" | sed 's/="\([^"]*\)"/=\1/g') | ||
| export "$line" | ||
| fi | ||
| done < "$env_file" | ||
|
|
||
| print_status "Environment variables loaded successfully" | ||
| else | ||
| print_warning ".env file not found at $env_file" | ||
| print_warning "Using default values or existing environment variables" | ||
| fi | ||
| } |
There was a problem hiding this comment.
Why export variables and not just source the .env file in the bash script?
There was a problem hiding this comment.
To trap error conditions.
In most versions of bash,source $FILEPATH where FILEPATH is empty or non-existent, bash will not complain.
| # populate_markets.sh | ||
| # Script to populate the SocialPredict database with example markets | ||
|
|
||
| set -e |
There was a problem hiding this comment.
I would suggest using
set -o errexit
set -o nounset
set -o pipefail
in all bash scripts as a precaution.
| # Usage: ./seed_markets_go.sh [SQL_FILE] | ||
| # Default: example_markets.sql | ||
|
|
||
| set -e |
There was a problem hiding this comment.
I would suggest using
set -o errexit
set -o nounset
set -o pipefail
in all bash scripts as a precaution.
There was a problem hiding this comment.
lol. same issue, different file... in the previous comment you said 'in all bash scripts' ;)
| # Strip quotes from values | ||
| line=$(echo "$line" | sed "s/='\([^']*\)'/=\1/g" | sed 's/="\([^"]*\)"/=\1/g') |
There was a problem hiding this comment.
Hm. Hadn't considered that. Then again, it's been a long time since I had to write bash scripts. ;-)
The problem here is that without striping quotes you can end up with export foo=''bar'' (double single quotes) which would be BAD™ :-)
Perhaps it might be better to parse out {$NAME}={$VALUE}, strip quotes from value and then export $NAME="$VALUE"?
Thoughts?
4 participants
NOTE: Pushed here by mistake. Mea culpa.
Enhancement: Custom Market Resolution Labels with Emoji Support
Overview
This PR introduces a comprehensive custom labeling system for markets, allowing users to create more expressive and contextual market options beyond the standard "YES/NO" labels. The implementation includes emoji picker integration and dynamic UI updates throughout the application.
IMPORTANT: This change is really only cosmetic as it only affects the UI by allowing new markets to use other text labels than 'YES' and 'NO'. There are no changes to the business logic which still uses 'YES' and 'NO' internally for market resolution.
Key Features
🎯 Custom Market Labels
yes_labelandno_labelfields to the Market model😀 Emoji Picker Integration
EmojiPickerInputcomponent usingemoji-picker-react🎨 Dynamic UI Updates
getMarketLabels()function for consistent label retrieval🔄 Component-Wide Integration
Updated 18+ components across the application:
Technical Implementation
Backend Changes
models/market.go: Added custom label fields with validationhandlers/markets/createmarket.go: Updated market creation logichandlers/marketpublicresponse/: Enhanced public API responsesFrontend Changes
EmojiPickerInput.jsx: Reusable emoji-enabled input componentemoji-picker-react@4.14.0Key Features
User Experience Improvements
Example Use Cases
Testing
Breaking Changes
None - this is a fully backward-compatible enhancement.
Migration Notes
This enhancement significantly improves the user experience by allowing more expressive and contextual market creation while maintaining full backward compatibility with existing functionality.