⚠️ Betting involves risk of loss.
See www.begambleaware.org
```
- Display problem gambling hotline number
- Add age verification if required by jurisdiction
- Implement loss-limit warnings if tracking customer activity
## Testing and Quality Assurance
### Automated Testing
1. **Unit tests**: Odds formatting, data validation (Jest/Mocha)
2. **Integration tests**: API communication, data updates (Cypress/Playwright)
3. **Performance tests**: Load time, update latency (Lighthouse, WebPageTest)
4. **Accessibility tests**: WCAG compliance (axe DevTools, WAVE)
### Browser and Device Coverage
Test across:
- **Browsers**: Chrome, Firefox, Safari, Edge (latest + 1 version back)
- **Devices**: iPhone, Android, iPad, desktop (1920×1080, 1366×768, mobile viewports)
- **Network conditions**: 4G, 3G, offline simulation (Chrome DevTools throttling)
### Performance Benchmarking
Establish baseline metrics:
```
Load time: 350ms p50, 500ms p95
Update latency: 100ms p50, 300ms p95
Interaction latency: <100ms
Memory usage: <15MB
CPU usage: <5% during updates
```
Monitor continuously and alert if metrics exceed thresholds.
## Common Implementation Mistakes to Avoid
1. **Blocking page load**: Don't load widget synchronously; always async
2. **Layout shift on updates**: Use fixed-size cells to prevent CLS
3. **Missing fallback**: Display reasonable fallback if API fails
4. **No error handling**: Implement try-catch around API calls
5. **Hardcoded styling**: Use CSS variables for theming flexibility
6. **No mobile optimisation**: Odds grid must be usable on mobile
7. **Stale odds**: Always show when odds were last updated
8. **Poor accessibility**: Implement keyboard navigation and screen reader support
9. **No performance monitoring**: Can't improve what you don't measure
10. **Over-engineering**: Simpler is better (avoid unnecessary animations, transitions)
## FAQ: Widget Implementation
**Q: Should I use iFrame or inline JavaScript for widget embedding?**
A: JavaScript is preferred. iFrames work but have downsides: harder to style, slower to load, can't share cookies/storage. Inline JavaScript loads faster and integrates better.
**Q: How do I handle timezone differences in odds?**
A: Use ISO 8601 timestamps (UTC). Convert to user's local timezone on the client side using Intl API or date library (date-fns, day.js).
**Q: What's the best way to handle API rate limiting?**
A: Implement client-side request queuing. Batch updates (one API call per 10-30 seconds) rather than one call per market. Cache API responses aggressively.
**Q: How do I implement dark mode for odds widgets?**
A: Use CSS custom properties (variables) for colors. Detect prefers-color-scheme media query. Allow user override in settings. Example: `--background: light-dark(white, #333)`.
**Q: Can I embed the same widget multiple times on one page?**
A: Yes, but be mindful of performance. Each widget triggers API calls. Implement shared state management or single API call with multiple widgets consuming from shared data.
**Q: What's the right update frequency for different sports?**
A: Pre-match: 30-60 seconds. In-play (football/soccer): 10-20 seconds. In-play (fast sports like basketball): 5-10 seconds. Adjust based on your data provider's latency.
**Q: Should odds be clickable or just display-only?**
A: Depends on context. Publisher display-only is simpler. Operator widgets typically should be clickable (add to betslip). Ensure mobile clickability (44px minimum target).
**Q: How do I prevent widget flash-of-unstyled-content (FOUC)?**
A: Load CSS immediately (before widget script). Use display: none on widget until fully loaded. Set fixed dimensions to prevent layout shift.
**Q: How should the widget handle timezone differences for events that haven't started yet?**
A: Display event times in user's local timezone. Include clear indicators:
- "Kicks off 2h 34m" (countdown timer that updates dynamically)
- "14:30 GMT" (explicit timezone with abbreviation)
- Handle daylight saving transitions gracefully
- Consider user preference to see all times in specific timezone (e.g., US users want ET regardless of VPN location)
- Sync countdown timers with NTP server to prevent client-side clock skew
**Q: Should the widget implement A/B testing for layout variations?**
A: Yes, but carefully. Test variations that improve primary metrics (click-through rate, bet placement). Avoid tests that increase layout shift or latency. Use feature flags to enable/disable variations without code deployment. Track which variations are winning with statistical significance testing (p<0.05).
## Widget Size and Layout Options
Different use cases require different widget dimensions:
### Standard Desktop Widget (600×300px)
Best for: Publisher sidebar, operator promotions
**Layout**: 6-8 columns × 3-4 rows
- Width: 600px
- Height: 300px
- Market count: 6-12 distinct markets
- Typical markets: 1X2, Totals, Handicaps, 2-3 props
CSS example:
```css
.odds-widget-standard {
width: 600px;
height: 300px;
overflow-y: auto;
border: 1px solid #ddd;
border-radius: 4px;
}
.odds-widget-standard .market {
display: grid;
grid-template-columns: repeat(6, 1fr);
gap: 8px;
padding: 8px;
}
```
### Compact Widget (300×200px)
Best for: Inline article embeds, limited space
**Layout**: 3-4 columns × 2-3 rows (with horizontal scroll)
- Width: 300px
- Height: 200px
- Market count: 3-6 distinct markets
- Typical markets: 1X2, Totals only
### Full-Width Widget (100%×variable)
Best for: Operator dashboard, comprehensive odds display
**Layout**: All markets visible, multi-row
- Width: 100% of container
- Height: Dynamic based on market count
- Market count: 15+ distinct markets
- All available markets displayed
### Mobile-Optimised Widget (responsive 0-600px)
Best for: Mobile operators, publisher mobile experience
**Layout**: 2-column mobile, 4-column tablet, 6+ desktop
- Width: 100% (responsive)
- Height: 200px mobile, 250px tablet, 300px desktop
- Touch-friendly: 44×44px minimum tap targets
### Ticker Widget (narrow, scrolling)
Best for: Continuous display of odds changes
**Layout**: Single column, wide, horizontal scroll
- Width: 1200px or 100%
- Height: 60px
- Shows: Market name + current odds, scrolls through all matches
- Auto-scroll: New matches appear from right
## Advanced Implementation Patterns
### Pattern 1: Skinning and Theme Customization
Enable flexible styling for different contexts (publisher vs. operator site):
```css
/* CSS Custom Properties for theming */
:root {
--odds-bg: #ffffff;
--odds-text: #333333;
--odds-border: #cccccc;
--odds-highlight: #d4edda;
--odds-font-size: 14px;
--odds-padding: 8px;
}
/* Dark mode variant */
[data-theme="dark"] {
--odds-bg: #2d2d2d;
--odds-text: #ffffff;
--odds-border: #444444;
--odds-highlight: #1e6622;
}
/* Compact variant */
[data-layout="compact"] {
--odds-font-size: 12px;
--odds-padding: 4px;
}
```
This approach lets same widget display differently based on context without code changes.
### Pattern 2: Virtual Scrolling for Large Tables
For widgets with hundreds of markets:
```javascript
class VirtualOddsGrid {
constructor(container, allOdds, visibleRows) {
this.container = container;
this.allOdds = allOdds;
this.visibleRows = visibleRows;
this.scrollTop = 0;
this.render();
this.container.addEventListener('scroll', () => this.onScroll());
}
onScroll() {
const newScrollTop = this.container.scrollTop;
if (Math.abs(newScrollTop - this.scrollTop) > 30) { // Only re-render on significant scroll
this.scrollTop = newScrollTop;
this.render();
}
}
render() {
const startIndex = Math.floor(this.scrollTop / rowHeight);
const endIndex = startIndex + this.visibleRows;
const visibleOdds = this.allOdds.slice(startIndex, endIndex);
// Render only visible rows, not entire table
this.container.innerHTML = this.buildHTML(visibleOdds, startIndex);
}
}
```
Virtual scrolling reduces DOM nodes from 1000+ to 20-30, dramatically improving performance.
### Pattern 3: Optimistic Updates
Update UI immediately when user interacts, verify with server:
```javascript
function selectOdds(oddsId, odds) {
// Optimistic: Update UI immediately
updateUIselection(oddsId);
// Pessimistic: Verify with server
api.validateOdds(oddsId, odds).then(response => {
if (!response.valid) {
// Odds have changed, revert UI
revertSelection();
showMessage('Odds changed, try again');
}
}).catch(() => {
revertSelection();
showNetworkError();
});
}
```
This pattern makes UI feel responsive even with network latency.
## Troubleshooting Common Widget Issues
### Issue: Widget loads but odds don't update
**Likely causes**:
1. API endpoint misconfigured (404 errors)
2. Data refresh interval is too long or not triggered
3. CORS policy blocking API calls
**Diagnostic steps**:
- Check browser console for JavaScript errors
- Check Network tab in DevTools for failed API requests
- Verify API endpoint is correct
- Check Access-Control-Allow-Origin headers
### Issue: Widget updates create layout shift
**Likely causes**:
1. Odds change cell size (e.g., 1.50 → 12.50 changes width)
2. Font-size changes on update
3. Padding/margin changes
**Solution**:
```css
.odds-cell {
width: 60px; /* Fixed width prevents shift */
height: 40px; /* Fixed height prevents shift */
overflow: hidden;
text-align: center;
}
```
### Issue: Mobile widget shows misaligned text
**Likely causes**:
1. Font size too large for small screen
2. Cell padding creates overflow
3. Viewport meta tag missing
**Solution**:
```html