[ ] drop vars rendering in the backend blocks. we see them in the inputs and in the live preview.
[ ] duplicate blocks.
[x] childfree blocks
[ ] blocks with children
[ ] entry_block -> message block -> reduce through all children and childrens children, process refs, vars, reset ids, generate uids.
[ ] create a "tag" for the message asking for child changesets, so we can reuse. (for live preview, for saving, for duplicating) — since we only need a single block (with tree) for dupes
[x] fix deleting block table row
[x] container and multimodule do not persist their active/collapsed values
[x] in brand guide lite project: create an asset MULTI, add a 50% media block, pick IMAGE and UPLOAD new image. add another 50% media block and the first block will reset its picture data. block.ex:395 -> send_child_position_update -- this is where it breaks
[x] live preview assign breaks in live_preview_opts since we don't have entry and language(?). Can we just put it in persistent_term straight from the render instead? store as {:live_preview_config, MyApp.MyContext.MySchema}. If so, we need to rewrite the assign logic to just store "getters" in the LP config map. We only cache in the render function after calling the getter.
[x] multi_select: select two new entries, edit title, then select one more. fails
[x] multi_select: when we send the selected_options as assoc to the form to update the entry and then run the form's "validate" it will treat the added option as an ":update" since it now finds the option as data in the changeset. Do we need to keep two entries here? A "pure" entry which we won't touch any of the assocs and an entry_for_blocks which we update assocs in and use for live preview. Will have the same problem with this entry_for_blocks, since we apply changes to this as well? Could we maintain an "updated_assocs" map which we merge in after the changes have been applied? Then we might not need the entry_for_blocks at all.
[x] don't update Image's creator (from imagedrawer) if we don't do anything!
[x] Investigate why meta_title keeps updating (it's the _target in form's validate). This is when we push_event b:validate, since it's the first input in the form.
[x] Rewrite subforms with sort_param, drop_param and make sure it works with image/file/select
[x] Update liquid splits picture vars on changed assets in form
[x] Update liquid splits vars from RenderVar
[x] pass an event to RenderVar that we can run after updating var (image/file)
[x] this event will refresh liquid splits var with value
[x] brand_evidi uses the identity.palette in its app.html.heex. How can we refresh this when changing the palette in form?
[x] allow supplying module FILE VAR with config target (so we can have custom upload dir / etc)
[x] #2355
[ ] #2356
[x] follow same procedure for block children as block entries wrt streams? Only load stream first time then update by send_update.
[x] Update SELECT var does not update var's value in LP (used hook PublishInput)
[x] LivePreview: How do we handle updating form fields which are referenced outside the block field, for instance in the template? We could have a custom background color that should update on validation, or a cover image that should update.
This will work as long as we are inside <main>. Any changes on the <main> element itself won't show up in LP.
[x] GalleryBlock
[x] won't reposition correctly each time on drag and drop sort
[x] Implement events
[x] Block with datasource selection
[x] Reproduction ①
Select two identifiers
Save
Select two more
Open Live Preview
Block resets to two identifiers
[x] Reproduction ②
Select two identifiers
Save
Select two more
Edit the entry title
Wait for it to validate
Edit the entry title again
Block resets to two identifiers
culprit is assign_entry_for_blocks in "validate" event in form.ex component
[x] send_update every changed field in the form's validate to all blocks, since we're not updating it now. Since we do this we can remove the apply_change'd entry on every validate.
[x] can we send_after when asking for root_blocks with a value higher than the debounce? currently we may risk not getting an update in flight if we save before validate_block is called
[x] Datasource.update_datasource — filter out blocks that need updating if they belong to entry. They were just updated, no need to save again.
[x] ModuleUpdateLive — when saving module, reapply module to all blocks who reference it
[x] update vars
[x] update refs
[x] rerender block
[x] if we do not rerender the block we might run into trouble when SEARCHING with regex through blocks.
[x] multiselect that updates :has_many that also is referenced through a :has_many through assoc, will not get updated in the changeset/live preview.
For instance in Rom, where we have article_contributors and contributors, and contributors is the one referenced in the template, it won't update when we update the article_contributors relation.
[x] discrepancy between iframe'd live preview and "Open preview in new window". It will load the old cached html. can we force an update of the cached html when opening the window? or should we just continuously update the cache?
[x] don't update rendered_at unless the render actually changed.
[x] don't recreate renders for OTHER entries that are deleted/draft (like entries getting affected by module updates etc)
[x] don't clear out caption/title for PictureBlock when replacing picture/uploading new picture.
[x] insert new block, other rendered_html is nil.
[x] refresh block fields when loading revision
[x] color var with palette does not work. Won't reopen. (ie - rom colored hero)
[x] boolean vars do not update logic in rendered code. is this because they think they are TRUE no matter what? look into :value_boolean
[x] PictureBlock data - sizes gets broken by "_unused" stuff
[x] Block: If rendered_html and rendered_at == nil, assign_new rendered_html
Migrations
[x] Migrate embed page.vars -> relation vars
[x] Migrate embed global_set.globals -> relation vars
[x] Migrate table block cols -> block table_rows and table_template
[x] module has table ref. table_block.data has a :template_row with :cols. Extract these to a list of vars that we store in the module's table_template assoc
[x] block has table ref. table_block.data has an embeds_many :rows. Extract these to a list of TableRow and store in the block's table_rows assoc
[x] Add source to blocks -> points to join_table source
villain.ex
[x] Rewrite all rerender_* logic
[x] update_module_in_fields
first process all blocks with module_id -> reapply_module
[x] add toolbar to the block editor, since the main toolbar is only sticky to the form above. Alternatively, move the form toolbar out of the parent form and target form fields?
[x] toolbar — replace description attr with a slot -- so we can pass from refs/block
live preview
[x] store rendered_html in each block
[x] give all [b-tpl] blocks an b-uid={uid} attr we can use for updating
[x] build a component for rendering all blocks.
[x] each rendered block is a live_component with id = "renderedblock" which means we can send_update to it and update on fresh render?
subentries
[x] extract entry_template to its own module and set parent_id to the entry id
[x] mark entry_template module (so we can provide a separate + button that only adds entry_template)
datasource
[x] a join table between block -> identifier?
[ ] Create a LiveComponent so we can keep the state of the fetched identifiers, instead of fetching every render.
Fragment block
[ ] create a new block type?
ModulesListLive
[x] query with parent_id: nil, but add children (as +)
ModuleUpdateLive
[x] drop all entry related stuff (entry_delete_ref / vars etc)
would be nice to split out these as well, since we could have more reactivity on changed videos/pictures if we want to assoc picture/video blocks to actual image/video-entries.
If we keep the current style of copying images/videos to the blocks, there's little upside here
I think we keep as is now and accept the jsonb search penalty
Bugs/todo
assign
breaks in live_preview_opts since we don't have entry and language(?). Can we just put it in persistent_term straight from therender
instead? store as{:live_preview_config, MyApp.MyContext.MySchema}
. If so, we need to rewrite theassign
logic to just store "getters" in the LP config map. We only cache in the render function after calling the getter.entry
and then run the form's "validate" it will treat the added option as an ":update" since it now finds the option as data in the changeset. Do we need to keep two entries here? A "pure" entry which we won't touch any of the assocs and anentry_for_blocks
which we update assocs in and use for live preview. Will have the same problem with thisentry_for_blocks
, since we apply changes to this as well? Could we maintain an "updated_assocs" map which we merge in after the changes have been applied? Then we might not need theentry_for_blocks
at all._target
in form's validate). This is when we push_eventb:validate
, since it's the first input in the form.<main>
. Any changes on the<main>
element itself won't show up in LP.assign_entry_for_blocks
in"validate"
event inform.ex
componentvalidate
to all blocks, since we're not updating it now. Since we do this we can remove the apply_change'd entry on every validate.entry
. They were just updated, no need to save again.rendered_at
unless the render actually changed.Table blocks
content_blocks
->content_table_templates
->content_vars
content_blocks
->content_table_rows
->content_vars
Rendering
Migrations
table
ref. table_block.data has a :template_row with :cols. Extract these to a list of vars that we store in the module'stable_template
assoctable
ref. table_block.data has an embeds_many:rows
. Extract these to a list of TableRow and store in the block'stable_rows
assocsource
to blocks -> points to join_table sourcevillain.ex
rerender_*
logicBlueprint
attribute :data, :villain
-- :villain attr -> proposerelation :blocks, :has_many, :blocks
UI
description
attr with a slot -- so we can pass from refs/blocklive preview
rendered_html
in each blocksubentries
datasource
Fragment block
ModulesListLive
ModuleUpdateLive