Forecast - Actual column split

[brettedw]

• splits out forecast and actual columns
• removes N/A for forecast-able cells
• disables cells for previous dates
• No 'Actual' label in Actual column

closes #3394

Test Links:

Landing Page
MoreCast 2.0
Percentile Calculator
MoreCast
C-Haines
FireBat
FireBat bookmark
Auto Spatial Advisory (ASA)
HFI Calculator

[codecov]

Codecov Report

Attention: 5 lines in your changes are missing coverage. Please review.

Comparison is base (df91b76) 81.08% compared to head (2fad87a) 81.04%.
Report is 2 commits behind head on main.

❗ Current head 2fad87a differs from pull request most recent head 16dbe65. Consider uploading reports for the commit 16dbe65 to get more accurate results

Files	Patch %	Lines
...res/moreCast2/components/GridComponentRenderer.tsx	83.33%	0 Missing and 3 partials ⚠️
...c/features/moreCast2/components/TabbedDataGrid.tsx	0.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3405      +/-   ##
==========================================
- Coverage   81.08%   81.04%   -0.04%     
==========================================
  Files         280      280              
  Lines        9805     9815      +10     
  Branches      454      459       +5     
==========================================
+ Hits         7950     7955       +5     
- Misses       1733     1736       +3     
- Partials      122      124       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[conbrad]

Looking good, thanks for tests! I'm wondering if we should model the grass curing cell differently from forecast/actual or if it's worth the effort to include the distinction. I guess a grass curing value is an actual?

[conbrad]

I know this is relatively simple, but could we pull this out into a helper function? Would make it easier to test and keep renderForecastCellWith focused on the rendering.

[brettedw]

Yep I can do that. I was also thinking the logic on line 85, setting value might be better to put in the predictionItemValueFormatter....it would keep formatting in the Formatter. Worth changing?

[conbrad]

Yeah I think that's a good call too

[brettedw]

Looking good, thanks for tests! I'm wondering if we should model the grass curing cell differently from forecast/actual or if it's worth the effort to include the distinction. I guess a grass curing value is an actual?

I initially thought the forecast/actual was the way to go for GC. It kind of makes sense, there is an 'actual' or 'estimated actual' and a 'forecast' as BS pointed out. Having an Actual also makes it nice and easy to disable the cells when an 'Actual' is posted. Honestly I'm not sure what the best way to go is, and what's worth the effort. Open to ideas

[dgboss]

Nice work! I think it looks good once the changes you and Conor commented on are implemented.

[conbrad]

Looking good, thanks for tests! I'm wondering if we should model the grass curing cell differently from forecast/actual or if it's worth the effort to include the distinction. I guess a grass curing value is an actual?

I initially thought the forecast/actual was the way to go for GC. It kind of makes sense, there is an 'actual' or 'estimated actual' and a 'forecast' as Brett Soderholm pointed out. Having an Actual also makes it nice and easy to disable the cells when an 'Actual' is posted. Honestly I'm not sure what the best way to go is, and what's worth the effort. Open to ideas

Ok cool, yeah I think this makes sense. If there was more divergence in the way GC works and it felt like fitting a square peg in a round hole it'd probably be worth the effort to implement a separate code path, but it seems to fit the model, at least for now.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud