Dataset text overlaying itself in the panel


Mac OS X version 10.12.1

I'm using Subform 0.0.0 8afa768 on Darwin 16.1.0 and am having trouble when creating datasets with large amounts of copy.

Steps to reproduce
• Create text field, add in a paragraphs amount of text.
• Duplicate text field
• Create new datum and add in another paragraphs worth of text


Desired outcome
A neater list

Other ideas
You can only link a text field to a dataset by duplicating one that's already a part of the dataset. It would be good if you could link a new text field to a dataset by typing it's name (providing you've named the dataset) in the Dataset name input.

2016.12.23 Subform release bb1f015

The text variants are all quite rough, as you can see.
Re: your "other ideas", you can actually change the dataset that a text field is linked to using the smarty bar: Select the text field, then type the dataset name in the smarty bar.

For a neater list, the easiest thing for us to do would be to expand the height of the rows, but that solution won't really scale for text variants where each datum may be a few paragraphs long --- in that case you'd probably want to name each datum ("article A", "article B", ...).
That's a lot of extra UI and conceptual complexity compared to what we have now, though.
Honestly, we'd probably want to know more about how you're using the tool and see if there are better solutions entirely (e.g., read text in from a separate JSON file, API, or google doc).

But in the short term, we can probably expand the row height in that control.
@ryan, any objections?


I think for a short-term solution, we've be better served by truncating the text, rather than having taller rows. I'll take a look at getting this fixed up for the next release.


Yeh just a sample of the text would be sufficient for now rather than the entire thing. Something I'm hoping to use Subform for in the future is a e-commerce site our studio runs which has hundreds of products. So in regards to how the text is updated something external that can be accessed by the product team would be pretty handy whether that's a JSON file, API, or google doc.


Ah I see, cheers @kevin. I have stumbled into another issue now though is that you can't use different datasets on components. So for instance I'm making some cards components varients that both share the same tertiary link components within them. Ideally these links would pull through two different datasets. Is this an issue you've encountered?


Let me make sure I understand what you're trying to do.
You have a component, and in state A there is a text box associated with dataset D1.
You place a second instance of the component, set it to state A, but you want the text box in that instance to be associated with D2.

Is that correct?

If so, that's the behavior we intended.
Changing the dataset of the text will propagate to all instances, just like a change to the text's color or size will propagate to all instances.

If you need it to be different, you can make another component or another state within that same component.


Not exactly.

So the main component in question is a tertiary link. Nothing complicated, just a textfield with an icon to the right (see attached photo).

It's handy just being able to call one of these in by the smart bar at the bottom as and when needed and also the ability to update the icon and text styling easily with it being a component - so far so good.

But the issue is that these are going to be used in hundreds of places across a large site with varying text so with the functionality as it is I'd be required to make all of them as hundreds of states of the component, each with a different entry in the dataset. Ideally there'd be the option to not have the textfield content linked in the component so I can just update the copy without having to make new states every time.

Hopefully that makes more sense :stuck_out_tongue:


Can't you just make each text variant a different datum in the same dataset? Components in a single state can have different data variants selected.


That's what I'm currently doing but it would be good if you could apply different datasets so you can organise content better, otherwise if I put them all in 1 dataset for a site I've got on in the minute there would be over 100+ entries in 1 dataset. It would be helpful if I could organise them into different datasets for links that are specific to certain areas of the site.


Ah, got it.

You want to use a component to maintain visual consistency for the text styling and icon, but you want several datasets to group the text itself across independent dimensions (the sections of your site).

Components are tricky, since people tend to expect instances to be "the same", but then there are cases where they want it to be "the same, except for X".

There are definitely use cases to allow variation between instances of components, but we want to make sure we understand them fully before making the semantics of components more complex.
(Ryan spent a lot of time convincing me to allow the current behavior, where data or the states of nested components can vary between different instances of the same component.)

Can you say more about why you want to group the text at all?
If you have so many variations (100+), why not just ignore the dataset panel entirely?
You can set every instance manually by holding "command" and double clicking the text to create and edit a new datum.


Ah I didn't realise you could do this, that might be something I could try. The main reason for grouping would be the ease of changing them down the line. So in the example above the line 'Explore all posters' may be used in several places but would always be in relation to the 'Product types' so could be grouped within that dataset. But then at some point the copywriter/client may ask to change it to 'See all posters' which without a dataset would be a tedious manual task finding all instances.


Got it, thanks for the clarification.

The "command double click" still creates a datum, and it's possible to have multiple data with the same value. (which would prevent you from changing one and having it propagate to all other instances).

Your use case makes sense.
Not sure if the best solution for that is in the dataset system as is, or if it's something orthogonal (like a "find and replace" command).