-
Notifications
You must be signed in to change notification settings - Fork 4
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
Implement the ReferenceEditor component #120
base: master
Are you sure you want to change the base?
Conversation
I'm a little confused on a couple of things. Perhaps you can clarify.
Where did that name come from? I am not following the logic of the naming scheme.
Looking at the docs, it looks like the props
I don't remember the discussion, but what exactly is the issue? Is the dependent component from Draft Plugins requiring CSS is its files? Or where are the stylesheets being included that are causing the problem? |
As in, a comfortable and properly set up editor. Happy to change whatever you deem appropriate. The name of the component wasn't specified, and Editor2 wouldn't be better.
It's true that you kinda can specify an entry component in the mention list. You can't, however, make the Another issue is that that
Yep, seems like autoprefixer issue; it needs browser environment to detect what to prefix. Obviously there is none. |
I guess since the issue was "reference editor component", I assumed it would be called that. We will be using the normal
The default looks very out of place in the material world, and I am not seeing any visual marking of either the hover or the keyboard focus in the Storybook. The spec was for the Material-UI components, so that's what I would like to see, please.
Can you be more specific? Where is the issue occurring? |
061dd1c
to
fec13ba
Compare
Re naming my bad, "reference" read like a verb there. Changed the list styling to drop the shadow and render individual items as material.
|
Ah! That makes much more sense now. I didn't notice the ambicategoricality. #wordoftheday 😄 |
Well, the material components fit better, but you make a good point about they keyboard navigation. They are also aggressively large. However, I think we can live with it for an MVP. cc @sethmerrick |
@joshdmiller I agree this will work for MVP, and also agree it leaves room to iterate into a solution that matches Material spec and offers keyboard navigation. |
@goshakkk Check out my new PR: #126. I think it should help with your unit testing. |
Hm, after rebasing on master, it looks like the css is wrapped into js for some reason when running tests:
|
The change I made isn't on master yet. |
@joshdmiller I know, and I cherry-picked it separately. The |
@goshakkk: What's the status of this PR? |
@joshdmiller that tests CSS issue is the only blocker |
fec13ba
to
8fc11be
Compare
@joshdmiller ok, ready for review now. |
@goshakkk Can you rebase against master? Some of those commits (like the base Editor) are already in there (as of yesterday, I think) and it will make the diff easier to browse. Thanks! |
8fc11be
to
e0aa770
Compare
import { cyan700, green700 } from 'material-ui/lib/styles/colors'; | ||
|
||
const MentionComponent = ({ mention, className, mentionPrefix, children }) => ( | ||
<a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be a react router Link
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Addressed
import MentionComponent from './mention-text'; | ||
import SuggestionsFactory from './suggestions'; | ||
|
||
export default function ({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this a factory?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To allow injecting plugins, to test
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am a little concerned with this approach. This makes the reference editor export a "factory factory" (i.e. a factory that returns a factory that returns a react component). And we must have all invocations throughout the application call a function that, as far as the calling code is concerned, doesn't do anything, just to make use of the component. And that's all just to make testing a little easier.
Can we approach this without the factory factory?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two other options would be:
- have private methods on the component that will return the instances of plugins and
UpstreamEditor
, then either expect those or stub — but this seems a bit too involved - export the actual instances of plugins and UpstreamEditor, and set expectations based on those
I've chosen to go the second road and pushed just now.
e0aa770
to
1c55f3a
Compare
@joshdmiller any updates? |
1c55f3a
to
5aac21f
Compare
import MentionComponent from './mention-text'; | ||
import SuggestionsFactory from './suggestions'; | ||
|
||
const Editor = EditorFactory(React); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The purpose of passing React
as an argument to the factory is to ensure the same instance is used everywhere. When done properly, there isn't the need to import React
at all. Let's move the call of this factory to inside the factory beneath so as to take advantage of that same instance.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, right!
import { shallow, mount } from 'enzyme'; | ||
import spy, { createSpy } from '../../utils/spy'; | ||
|
||
import { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't look like most of these are used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah... I feel like we could benefit from an eslint rule to detect unused identifiers
} | ||
|
||
{ | ||
const upstream = instance.find(UpstreamEditor).at(0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we're not creating a new instance, I don't think we need to re-find this.
{ | ||
const upstream = instance.find(UpstreamEditor).at(0); | ||
const plugins = upstream.props().plugins; | ||
t.notEquals(plugins.indexOf(mentionPlugin), -1, 'should manage mention plugin'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From looking at these tests, it seems the whole discussion about the "factory factory" might be related to just these three lines. If so, in the future, I don't feel this is something we would necessarily need to test. To some degree, it's just testing for a typo. If we wanted to be extra sure, we could check that the number of plugins passed matches our expectation, but I don't think we got a lot of value out of this particular set of assertions.
It's fine to leave, since the work is already done, but for the future, I consider stuff like this superfluous, so you need't worry about testing it too much.
|
||
const Editor = EditorFactory(React); | ||
|
||
import { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't look like we need all of these.
|
||
export default function (MentionSuggestions) { | ||
return ({ suggestions, ...rest }) => ( | ||
<MentionSuggestions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it help with styling if we wrapped this in a List
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not really, looks like there isn't a lot of styling in List
itself and ListItems
are just enough
5aac21f
to
b9cb062
Compare
Just pushed some updates |
Looks good. Let's just add the commit footer and call it done! |
@joshdmiller which commit footer? Is there any action required on my part? |
@goshakkk I believe @joshdmiller is requesting a new line at the end of the commit message to close the associated issue like You can see more specific details about the footer in https://github.com/StoryShop/app/blob/master/CONTRIBUTING.md#commit-messages and let me know if you have any questions. Thanks! |
b9cb062
to
94606f6
Compare
Done |
Ref GH-58
The PR is based on GH-61, which wasn't merged yet, so the diff view might be a bit less useful.
material-ui
obviously does not export the class names, as there are no class names to begin with.This change is