Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Table] EditableCell doesn't grow to match the row like EditableName does with defaultRowHeight set #1235

Closed
seansfkelley opened this issue Jun 14, 2017 · 4 comments

Comments

@seansfkelley
Copy link

seansfkelley commented Jun 14, 2017

Bug report

  • Package version(s): core: 1.20.0, table: 1.17.0
  • Browser and OS versions: Chrome 58.0.3029.110, OS X 10.12.5

Steps to reproduce

<Table numRows={1} defaultRowHeight={30}>
    <Column
        name="foo"
        renderCell={() => <EditableCell/>}
        renderColumnHeader={() => <ColumnHeaderCell renderName={() => <EditableName/>} />}
    />
</Table>

Actual behavior

Header has the right size:

image

But the cell doesn't:

image

Expected behavior

EditableCells grow to fit the size of their containing row.

This is extra sad because then the click target for the editable area is small even if the row is very large.

@seansfkelley seansfkelley changed the title table: EditableCell doesn't grow to match the container like EditableName does table: EditableCell doesn't grow to match the row like EditableName does with defaultRowHeight set Jun 14, 2017
@cmslewis cmslewis changed the title table: EditableCell doesn't grow to match the row like EditableName does with defaultRowHeight set [Table] EditableCell doesn't grow to match the row like EditableName does with defaultRowHeight set Jun 14, 2017
@cmslewis cmslewis added the P2 label Oct 2, 2017
@gscshoyru
Copy link
Contributor

To be clear, if we do this, it's going to look something like this:

screen shot 2017-10-05 at 11 41 37 am

Is that really what we want? @llorca

@gscshoyru
Copy link
Contributor

To be clear -- none of the text goes onto other lines, there, it's all on one line, even with all the vertical space.

@llorca
Copy link
Contributor

llorca commented Oct 5, 2017

@gscshoyru yeah that makes sense to me. One liner as a default, but theoretically text could wrap onto multiple lines if wrapping enabled

@gscshoyru
Copy link
Contributor

@llorca -- well, right now we just have inputs -- we'd need textarea to be able to do wrapping -- something to look into later -- but yeah, just wanted to be sure.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants