Repeater Control #298
Repeater Control #298
Conversation
|
This is still VERY early – it only includes 1 thing: An admin UI for adding / managing Repeater fields. The "Add Sub-Field" button doesn't even work yet. But I wanted to get an early review before heading too far down this path to make sure we're happy with the UX. What are your thoughts?
|
|
Hey @lukecarbis, |
|
Here is a mock of what the frontend could look like as well: https://user-images.githubusercontent.com/1578148/56863483-05b50280-69fa-11e9-9e28-cad86f719af2.png |
|
I actually disagree. I think the backend gets far too crowded like that. Since the headers are all the same, isn't it better to keep all the fields visible without clicking into the repeater? |
|
Added a commit which enables new Sub Fields to be added. There are still a few known issues (e.g. background colours when dragging, dragging sub-rows doesn't work, the auto-scroll doesn't go to the right place), but I just wanted to give you a little more of an idea on how this could work. |
|
Looks Good Hi @lukecarbis,
|
|
Short screencap of initial thoughts on the WIP. |
…hanging control types
…eater, in a repeater, in a repeater, in a repeater, in a repeater, in a repeater, in a repeater, in a repeater, in a repeater, in a repeater, in a repeater, in a repeater, etc.
|
@kienstra I merged #221 into this PR, since I know that it's got some changes that affect the repeater field. Progress so far: The UI for adding a repeater field should now be done. I still haven't gotten around to saving it, and I need to do a general tidy up of the CSS. But those should be the last things to do for the block editor side of things (still lots to do in the editor editor). @RobStino – could you please review the design / UX so far?
|
Before, in /wp-admin > Block Lab > Edit Block, it wasn't possible to save non-repeater fields. On clicking 'Update', any non-repeater fields didn't save. It looks like this is because $field->settings['parent'] was set, but empty. So instead, check for it being empty.
It looks like I had broken this, so it actually displayed the post ID, instead of the title. So allow it to show the title.
| <p className="bl-dot-tip read-more"> | ||
| <a href="https://github.com/getblocklab/block-lab/wiki/7.-FAQ" target="_blank">{__( 'Read more', 'block-lab' )}</a> | ||
| <a href="https://github.com/getblocklab/block-lab/wiki/7.-FAQ" target="_blank">{ __( 'Read more', 'block-lab' ) }</a> |
…ction property Now, it will simply look at the controls from controls/index.js This is the previous behavior.
js/blocks/components/fields.js
Outdated
js/blocks/components/fields.js
Outdated
| const attr = { ...parentBlockProps.attributes }; | ||
|
|
||
| // If the field has a parent, it's probably in a repeater row. | ||
| return ( field.parent && attr[ field.parent ][ rowIndex ] ) ? attr[ field.parent ][ rowIndex ][ field.name ] : attr[ field.name ]; |
As Luke mentioned, this is easier to understand.
As Luke mentioned, it'll be easier to have undefined === rowIndex than undefined !== rowIndex.
This was only used in one place, so it's not very necessary to have a separate file.
…ck-lab into feature/repeater
In block_sub_field(), there was an issue where calling a non-existent field name produced an error.
…ck-lab into feature/repeater
There was a workaround that added default values, but it didn't apply to sub-fields. Props Luke Carbis.
Before, the repeater attribute was an array. This will allow more flexibility, as the repeater can save more values in the future.
…ck-lab into feature/repeater
Closes #36.
Closes #391.