app-enter workouts to create new templates and save either local or to cloud?

[sagreine]

supports longer term thing. but also don't want this to be a "does everything app" maybe build a sample set of workouts. maybe store in using the form and encourage them to instead upload it? or, just use this for myself, and just do one that way....

[sagreine]

could make a 'premium' feature for this.

would then store in userdata as well as programs? - discussion below so closing here
don't necessarily want everyone to get access in case someone makes one that breaks everything or is dangerous..

[sagreine]

allow them to put something that's not a main lift as x % of a main lift 1RM.

[sagreine]

ask them if this is a program that has a "main" day ask them if it is based on % TM or 1Rm ask them for %TM but bring in a field to make it editable`` ask them if this program has different distinct - let them copy from week x to week y for creating it if so

ask them for a name of the program
have a 'copy this set' button and a 'delete this set button'
all them to save the program

^order all of these, then have a button that takes them to edit exercise page? would need that to read in the values there if so.

[sagreine]

how can we show this information back to them  / let them edit it?
- features of the program. long press on the program picker page?
- if they change things on the full day page, should we let them save the program from that? what about % vs absolute.

[sagreine]

FAB on full day to add a new exercise, not just copy? easy addition but see how it looks

[sagreine]

**set hasMainLifts on all default programs and reflect that in the cloud** before closing these tickets. use that instead of type = 5/3/1 to do so...**

[sagreine]

---------------------- pulls in. but, why not just have a list of ExerciseDayView?
------- provider is good, best really, but since we have to build them up front (do we?) we are getting the last week for every week.
- that's not good obviously.
- - also, if we change the week it is going to slam back to the first tab, which we don't want and just hacked around for now.

[sagreine]

what if we did - 

1) create excercise day outside of the build and assign it, then we save from there at the end. should let us persist.
--- still trouble from clicking the back button though?
only build the first week at the start. then, when we click next, save those updates^ and build the next one

how do we handle the back button not showing them the latest week though? will that be automatically handled by having exerciseDay and/or ExerciseDayView(State) creation done outside of the build (Consumer), that is, assignment instead of recreation?

^or, if we have the exerciseDays stored, we can simply save them all at the end, ya?

[sagreine]

okay, pulling in appropriately. but, need to save now.... 
that is, once you exit the Program Edit page it is gone.
but maybe that's fine, if we will save to cloud before that happens anyway?

but could also "cache" exercise days with this... that is:
1) when you press Edit or **you select the lift in Pick Day**
-we already have to pull in all the exercises for at least one week. 
why not have a model that saves them? in the program, even.
then, in Edit or Pick Day we could change it from:
-- immediately go to cloud
to
-- check if there is a local value
-- if so, use that
-- if not use cloud

to do this, when we update a program we need to go from:
-- update cloud
to
-- update local
-- update cloud

^ this is the approach we use elsewhere in the app to minimize pulls from cloud.

First, build it the simple way lol. 

[sagreine]

telll them how to put exercise1 | exercise2 in and etc. for 'Main' lifts if they want. 
or to have a Volume day and a Intensity day, for each lift. 

^support for this is in, but need to tell them they can do this.

[sagreine]

or do we want to back away from this and have a "weeks" piece? let them reorder, let them push a button to edit each one...
easier maintenance + new features + no more "oops you rebuilt" except there kind of still is..

`

if we don't do that, or maybe even if we do,`
look at having a futurebuilder and a non-futurebuilder to try and get around for the futurebuilder introviews flashing issue..
^but really still have to setState and rebuild, no? since you might pull more programs back in <-- would give that up to get rid of flashing, since it might be more annoying than anything anyway? 
but i think you do have to setState anyway and will have flashing. because you haven't built the widgets that will get displayed...
so maybe we need to try and hack in a way to know the current index?

[sagreine]

Don't add or copy f first, push to the new and only add if they complete it

[sagreine]

need to take care:
when we check for equality, need to do so deeply or be aware that we are doing so deeply. that is, even if we don't change any values of the program, we might change values of the exerciseDay in question. 

`this is evidence for pulling it down to programs and saving it - easy equality checking. `
need to take care to compare post-pull to post-pull though, lest we compare unedited to null...

might neeed to actually store weeks? or just do that as a getter for exerciseDays? created that on creation based on the orijginaal 'week' values? dangerous though....

[sagreine]

save edited is in!
need: 
add new
read back in
see about if we edit or not to things etc.
revise everything so we save what we want to save, too.

[sagreine]

Before releasing at all: -lots of testing

not done nor tested: -fix prescribed reps on edit screen i think this is done? -picking a day, then picking another day from the same program doesn't reset which is obviously no good - you basically have to close the app if you pick the wrong program. or at least pick a different one then repick this one..

post-release, for when this drops down the priority list. -------which lifts to show for reference dont update when we change the bar selected. why not?---------- -we actually overwrite the index for ordering every time (see copy from code) which is stupid and means we always update the cloud when we save, for every single set. obviously this is not what we want, but i am tired of working on this CR and this is just for fun and not going to learn anything chasing down this (easy) fix :) -need to override equality at the program level as well, so save on unnecessary program-level writes. -set these (uses barbell, %TM and which lift, etc.) variables for default programs, on the way in? i.e. while building the day. it isn't necessary for the lifts to populate correctly, but the reason is that when they go to the edit page they don't see anything reflect there. -where should we store this in firestore? in program, with a "any" for default else userId for "ids_with_access. would want to consider how we delete user data when they delete their account. -use the id not the substring of - copy to identify it... -ask them if this program has different distinct - let them start by copying from week x to week y for creating it if so -what fields do we not need to save ever? careful that we aren't stupidly checking equality via from/to json in that sense though. look at loading in - does it tell you which one you saved when you view on do lift? probably have issues around calculating weight etc. when going to isMain -don't display 'xRM and max Reps for' on exercise page when isMain is selected -note on exercise edit page if this is from full day or edit programs, tell them if it is / isn't saving the program or just the day -why can't we reach delete set on build program - make it also tappable? -put select program at top of do lift, then only show pick day if it is a thing. and, rework readiness to go with that. -when we edit exercise sets in program edit mode it is not reflected on the program builder view. por que --may be a simple assignment? cant seem to use a consumer and cant assign listeners manaully, so may need to revert to using the 'arguments' approach? or, a callback i guess? -stop calling function in build in introview so it stops flashing -check if updates are saved to cloud when we edit a single set on an already existing program -check that editing works if we go to the page on same runtime as creation, on separate **-need expandeds and etc. in full day view OR exercise view** -need to override equality + hash for (at least) exercises to allow not updating if there were no edits - honestly, a nice to have performance booster for now. -look at how we do Today and Full Day views - just use change notifier there? otherwise need to look at widget tree and figure out why the consumer isn't working on the build program view **-telll them how to put exercise1 | exercise2 in and etc. for 'Main' lifts if they want. - check this it might be fixed already: thisSetPRSet but that doesnt help us because we (have to) set against the controller value on do_lift view, not this flag. i think we came to this solution because otherwise it was adding xPR every time the page built, including when we edit the reps on that page. or, perhaps it was moving the cursor to the front with that. in any case, will need to refine that in concert with this and make sure whatever we do is correct there too. could do via focus + submit like we did here too... Do a lift that is main lift. Then go to pick lift page -> buttons still there though program is blank --- only let them set lifts to Main if the _program_ allows it because it is a main lift program -does the error checking happen for e.g. no null reps when using isMain? -do EITHER/BOTH barbell get selected as soon as you toggle them on? and the index too? if not why not. it does not look like it is saved in the exercise set unless you select a different one than default squat... -should calculate percentage number change trigger a weight + description recalc on not-building? either that, hide this when using, or make weight not readonly (this needs to happen anyway really, just have them stay in sync) when using -if you edit an existing program and save, it adds sets. this is likely meaning we need to define equality + hash but even if we don't, we need to know the firestore ID (or, rather, fix what is showing as different) of the given set to upsert, not just insert. -need to require a non-null percentage of 1rm lift if they are using that! -Weight that's bull should be blank on dolift. Recreate by making an RPE set then going to it on do lift -test if this is still true by copying a default one: -indexForOrdering needs to be set on default programs before closing -make program with 100% TM %. close out. edit program. shows 1 instead of 100 on both readin and edit screen.