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

Optional breakpoints and classes #3

Open
chenghong opened this issue Apr 14, 2014 · 4 comments
Open

Optional breakpoints and classes #3

chenghong opened this issue Apr 14, 2014 · 4 comments

Comments

@chenghong
Copy link

Is it possible to make "breakpoints" and "classes" optional, if I only intend to use the turbo classes? Guess this makes a feature request.

@obihill
Copy link
Owner

obihill commented Apr 14, 2014

At this time, you have to define both breakpoints and classes, but you don't have to actually use them i.e. you can set breakpoints to '10000', which will catch all devices with viewport width up to or less than 10,000 pixels; and set classes to any value you like, which will then add that value to the class attribute of the body tag.

What you want is the ability to define the turbo_classes option, without having to explicitly define breakpoints and classes?

@chenghong
Copy link
Author

Yes. If breakpoints and classes are made optional, I reckon it may save a few ms trying to determine the window dimension.

@obihill
Copy link
Owner

obihill commented Apr 15, 2014

That makes sense. Already did a lot of work with caching to make sure Restive.js is fast, but nothing wrong with going faster, so I'll see what we can do here. Thanks for the contribution.

@obihill
Copy link
Owner

obihill commented Apr 23, 2014

Hi chenghong,

I'm going to have to leave this as it is for now because of the way the code is setup. It's going to take a while to enable this optionality, but I'll definitely look into it as a feature request for the future (We're working on a version 2.0 so we'll look at it for that when the time comes).

Doing this now will require a significant structural change to the codebase that we simply can't deal with at this point because there's a lot of intricate parts in the code and I think the minor inconvenience of declaring breakpoints and classes options even when you want turbo_classes only is not enough to risk [knowingly or unknowingly] breaking some other functionality that other users may rely on.

Again, I appreciate you bringing this forward. I'm sure a few ms improvement in speed won't hurt but Restive.JS is already significantly optimized for speed so you probably wouldn't even notice the difference. But we will consider it as it really does make sense to do.

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

2 participants