Dropdown and Menu reimplementation

[javivelasco]

Dropdown component has issues in a similar fancy to #1169. Passing the source es problematic and it's way better to just allow rendering custom items so you can filter them, add separators, etc. Also it doesn't conform very well the spec since the selected option should be placed over the item, etc.

Also, this will come with a Menu reimplementation too. The Dropdown may be consider as an Input with a caret that opens a Menu with a set of selectable options. This will be a good moment to implement #249.

[dalefrancis88]

Hey @javivelasco, How's this going? Would you like some help with it?

[olegstepura]

@javivelasco is there any progress on this? I'm interested in #886 but just multilevel inline, with ability to fold inactive submenus (carousel-like folding would be nice).

In terms of composability of components I suggest it to be as following:

<Menu>
  <MenuItem value="Hello">
     <Menu minimized={false}>
       <MenuItem value="Hello inner" />
     </Menu>
  </MenuItem>
</Menu>

Visually inner elements should have a margin in the left.

Currently I can achive this with (and some extra styling):

<Menu>
  <MenuItem value="Hello" />
  <Menu>
    <MenuItem value="Hello inner" />
  </Menu>
</Menu>

I use Menu for Navigation menu in Sidebar. Please drop me a note if this is the wrong usage pattern.

[javivelasco]

@dalefrancis88 @olegstepura Hi guys, I couldn't progress on this yet but I want to give you an update on what's going on and why I wasn't answering issues this past week. I'm currently restructuring the project for a POC of style-agnostic components. For this POC I want to implement a complex component and I chose the DatePicker. I have it ready with Airbnb styles (https://twitter.com/javivelasco/status/831570140265340929) and also I have an implementation of the ripple in 4 different libraries (https://twitter.com/javivelasco/status/829770165847986176). I think I can get a react-native version too so I'm currently working on that to set a pattern. Also the project would be a monorepo for some different packages: react-toolbox-core, react-toolbox-web...

I want to set all of this up before rewriting those components so it can be done in this fancy. Truth is I have an implementation of the Dropdown and Autocomplete in other project so after the POC is ready it would not take too long. I'm afraid right now the best help I can get is with issues, once the pattern is set with the POC I can get more code help.

Hope it sounds promising!

[olegstepura]

@javivelasco Which styling library will react-toolbox-web v.2.0 final will be using? Will it continue to use postcss' cssnext with css-modules?

[dalefrancis88]

@javivelasco That sounds good, keep us informed :)

I am a bit confused though, what exactly would you like me to help with?

[javivelasco]

@olegstepura Styled Components looks like the best for me. I'm going to show the idea with the POC but the customization strategy is near to perfect and I'm making some tests for react native too. Will try to get it ready during this week

@dalefrancis88 I'm missing a communication channel for this kind of announcements. I'd like to warn people when I'm a bit off and can't pay too much attention to issues, I think Github is missing this. About the help: labeled issues are ready to be fixed, it would be helpful if you can take a look on them. Do not put too much effort on the Dropdown and Autocomplete because they need to be completely re-written. The rest of components would look pretty similar with this new strategy so any fix would be great. Also, I appreciate if you can help answering issues and questions about configuration.

Do you guys think we should release the current dev branch as stable with PostCSS and call the future version 3.0? I don't wan't people to be confused because we'd release a 2.0 and start speaking about 3.0 the same day :/

[dalefrancis88]

That's a pretty normal strategy, it's a normal thing to do.

…

On Mon, Feb 20, 2017 at 12:12 PM, Javi Velasco ***@***.***> wrote: @olegstepura <https://github.com/olegstepura> Styled Components looks like the best for me. I'm going to show the idea with the POC but the customization strategy is near to perfect and I'm making some tests for react native too. Will try to get it ready during this week @dalefrancis88 <https://github.com/dalefrancis88> I'm missing a communication channel for this kind of announcements. I'd like to warn people when I'm a bit off and can't pay too much attention to issues, I think Github is missing this. About the help: labeled issues are ready to be fixed, it would be helpful if you can take a look on them. Do not put too much effort on the Dropdown and Autocomplete because they need to be completely re-written. The rest of components would look pretty similar with this new strategy so any fix would be great. Also, I appreciate if you can help answering issues and questions about configuration. Do you guys think we should release the current dev branch as stable with PostCSS and call the future version 3.0? I don't wan't people to be confused because we'd release a 2.0 and start speaking about 3.0 the same day :/ — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1170 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB0iTdFcMC4FIqP8zQOCzMUvihes2qIxks5reOh_gaJpZM4LqzCr> .

[dalefrancis88]

@olegstepura, If 2.0 was released it would mean that people could use and test it. Any updates could be merged into 3.0

That being said, don't forget that major version increments should be reserved for breaking changes so if its not a breaking change to use the new version it may not need to be 2.0

[javivelasco]

It's breaking to 1.0 because we switched from SASS to PostCSS. The real issue about merging from that 2.0 to potential 3.0 is that the project would be restructured meaning constant conflicts. Maybe it could be released after this restructure.

[olegstepura]

Well, I think 2.0, since it's already beta, should be released with postcss. Not sure if selection of styled components is great, but if it solves issues like #1240, it actually is. This case 3.0 can be a split + another change of styling lib.

[javivelasco]

Ok, I will push the POC and then release 2.0 tagged as stable. I think it makes sense. The only issue is that we need to fix the documentation project which is not working in dev atm

[javivelasco]

@olegstepura it's working so perfect. You'll see 💃

[olegstepura]

@javivelasco issues appear when people start testing 2.0. I don't think it's ready to be released as stable in current state.

Since there is no publicly visible progress on your POC no one can assits you knowing that all the things will change again. Maybe it's a good idea to create a public branch or introduce separate repos with your POC?

[javivelasco]

Sorry @olegstepura I had some personal issues and couldn't work on anything at all. Will try to finish the POC and push it into a PR that doesn't need to be merged immediately. The main idea is to split react-toolbox into multiple packages. One of those packages can be the 2.0 version and everything else can evolve in the same repository and released as different packages.

What do you think about that?

[olegstepura]

@javivelasco here are my thoughts on the project (may not be well structured, but hopefully clear):

1. I think a split to core + dom is good way to go (well, according to my thoughts below, it may be a goal for 2.0 already). native should be a future goal, not current.
2. Current version with postcss seem to be kind of limited. If you insist that styled-components solve some core issues (like Primary color switching in single app in 2.0 #1240) which postcss cannot (and that styled-components look amazing), it may be good idea to actually release 2.0 with styled-components (only if the switch will not take much of effort for end users and for you). As far as I can tell there is no styling hardcoded in components, so it may happen that a switch to styled-components is easy (and is actually a routine work). Also there is Dark theme #1177 which is actually a stress test for current styling lib.
3. There is a lot of issues opened for current beta. This all need to be fixed before the first release candidate. Also I believe some more will appear before the release (and should be fixed as well).
4. Current release cycle is too slow. Some issues are fixed but not released and are reported again. It would definitely make sense to release more often.
5. Nothing should be developed privately. When there is some work going, project looks alive (!) and people may help and discuss the further way to evolve. Git has branches! ;)
6. This one doubtful, but maybe there is a need to add some more contributors to the organization. I'm not talking of myself, my time is too limited, but there may be some contributors you trust.

[javivelasco]

Thanks for that comment @olegstepura! Let me comment over the same bullet points:

1. I agree, native is definitively a future goal but for this first POC on agnostic components I wanted to make sure it is possible to write components for both native and web with any style. I'm very very close to finishing it but, after that, we should go first for web, then native.
2. Styled Components fixes those issues for sure! Generating styles from CSS is really really powerful. The main idea of 2.0 was to move everything to PostCSS but this idea of agnostic components came out in the middle, and it's not worthy to keep working on components styled with css while we have this migration in the road. About the work needed for this migration, the POC will show up how easy/difficult it is. For some components it will be pretty straightforward but for others it might be complex. The return is going to be HUGE tho.
3. I agree with you. The main problem I have with this is that it's near to impossible to keep working on the future version and researching a bit which patterns can be used to migrate everything. I have a fulltime job apart from this and a project this size needs more resources. The only way to solve issues and fix bugs is to get help not only fixing but reviewing PRs, checking on issues. So far the community is growing but still it gets out of hands sometimes.
4. This is totally on me. It's easy to release more often and I'm not doing it: my bad.
5. Yeah, my bad too. I should be more transparent on the development process.
6. I'd love to! But I need to get people working frequently on the project. Until now most people come and go :(

So, actions I'm going to take this week:

• Reviewing all pending issues and PRs.
• Releasing a new beta version with all submitted fixes.
• Uploading a branch with the POC of this agnostic components thing.

After all of this I think we can be ready to evaluate the amount of work needed for the migration and if it's worthy to release an RC of 2.0 and keep focused on 3.0 or just go with the migration for 2.0. (I'm more likely to the latter)

[javivelasco]

Also, feel free to speak to me privately though Discord or hangouts, @olegstepura or any other interested in helping. Just had a call with @izakfilmalter yesterday and it was cool :)

[prestontighe]

@javivelasco Any luck on #249?