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

List of breaking changes for Likely 3 #76

Closed
5 tasks
iamakulov opened this issue Jul 15, 2016 · 12 comments
Closed
5 tasks

List of breaking changes for Likely 3 #76

iamakulov opened this issue Jul 15, 2016 · 12 comments
Labels
3.0 Roadmap for the next version Blueprint
Milestone

Comments

@iamakulov
Copy link
Collaborator

iamakulov commented Jul 15, 2016

Likely 3 should include some major feature additions, and we want to bind several breaking changes to this release. There’s neither a concrete date nor a concrete list of features for this version.

  • Bundle both JS and CSS into one file. This will let us get rid of Gulp and switch to Webpack completely.
  • Remove likely.initate() which is an alias for likely.initiate() and was originally introduced by a mistake.
  • Remove likely() in favor of likely.initiate() (see Clarify section about using API #82 (comment)).
  • Join .likely_visible and .likely_ready into a single class: it’s unclear why they are ever separate. (This could probably be a large breaking change because people can rely on one of these classes.)
  • Make Likely auto-initialize when being used as a CommonJS module.

The list will most likely be expanded in the future.

@iamakulov iamakulov added this to the 3.0 milestone Jul 15, 2016
@vitkarpov
Copy link
Collaborator

vitkarpov commented Jul 16, 2016

Bundle both JS and CSS into one file

What does it mean exactly? I didn't get it right, I think.

@iamakulov
Copy link
Collaborator Author

What does it mean exactly?

I think of doing require('../styles/likely.styl') in index.js (with 'style?insertAt=top!css!stylus loader). Webpack will load likely.styl, compile it into CSS and bundle it together with the JS code into release/likely.js. Then, Webpack will automatically add the styles to <head> when likely.js is loaded in the browser. (insertAt=top is required to make the user styles have more priority than ours.)

Have I explained OK or is something unclear?

@iamakulov
Copy link
Collaborator Author

BTW, I don’t yet know if this behavior is OK for users that use Likely in SPAs. I’ll try collecting more data when we get nearer to 3.0.

@vitkarpov
Copy link
Collaborator

Yep, this seems okay. Thank you.

It completely changes the way Likely's being added to the page, and I think about flashes of unstyled content.

Correct me if I'm wrong.

Browser gets button in html:

<div class="likely">
    <div class="facebook">Share</div>
    <div class="twitter">Tweet</div>
    <div class="gplus">+1</div>
    <div class="vkontakte">Share</div>
    <div class="pinterest">Pin</div>
    <div class="odnoklassniki">Like</div>
    <div class="telegram">Send</div>
</div>

In the previous scheme we had css loaded in the head section, and to the moment browser parsed this html, all styles were ready to be applied to it.

Now we have a script which adds styles dynamically to the head, and usually scripts are in the end of the page, so at this moment we have no styles for button, right?

@iamakulov
Copy link
Collaborator Author

iamakulov commented Jul 16, 2016

I think about flashes of unstyled content

Hm, good point, thanks! I’ll discuss this with @ilyabirman later, probably we won’t do bundling.

@iamakulov
Copy link
Collaborator Author

I think about flashes of unstyled content

Or probably there won’t be: as far as I remember, the browser don’t display anything untill all the HTML is parsed and all the scripts are executed, so if we add styles synchronously, we won’t experience anything. (Should be tested though.)

@iamakulov
Copy link
Collaborator Author

Added a new point:

  • Join .likely_visible and .likely_ready into a single class: it’s unclear why they are ever separate. (This could probably be a large breaking change because people can rely on one of these classes.)

@iamakulov
Copy link
Collaborator Author

iamakulov commented Dec 17, 2016

Added a new point following a discussion with @ilyabirman:

  • Make Likely auto-initialize when being used as a CommonJS module.

@vitkarpov
Copy link
Collaborator

vitkarpov commented Dec 17, 2016

Make Likely auto-initialize when being used as a CommonJS module.

Could this be optional? (on by default, if you will). I think SPA developers may want to start up buttons in custom moment of time (because of complex app init)

@vitkarpov
Copy link
Collaborator

vitkarpov commented Dec 17, 2016

Bundle both JS and CSS into one file.

Also, I think I got the main idea of @ilyabirman — it should be less interfaces as possible: instead of 2 files it should be one, instead of handy initiate it should be auto and etc.

I totally agree with it! As developers we face challenges (such as FOUC) and have to tackle it instead of doing everything the same as before.

@iamakulov
Copy link
Collaborator Author

Could this be optional? (on by default, if you will). I think SPA developers may want to start up buttons in custom moment of time (because of complex app init)

Yeah, likely.initiate() is still there, it’s just that it’ll be automatically called when importing the package.

@NikolayRys NikolayRys added the 3.0 Roadmap for the next version label Dec 24, 2019
@NikolayRys
Copy link
Owner

Closed in favor of #163

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3.0 Roadmap for the next version Blueprint
Projects
None yet
Development

No branches or pull requests

3 participants