jakearchibald / tweetdeck-prototype Goto Github PK

Hello. I have an error in chrome console:
TypeError: Cannot read property 'find' of undefined
at TweetDeck.TD.extractAccountForUser (index.js:152)

Homescreen icon, chromeless launch.

Just thief the design the Twitter app uses. Put the interaction elements (fav, retweet etc) in their own element so they can be hidden until we implement.

Update the stuff in https://github.com/Polymer/topeka/tree/master/polyfills

I'm open to better ideas on design, but failing that:

Mobile view:

Sticky header across the top, with twitter logo, then a secondary menu bar for column titles. Obviously they won't all fit, we'll let the titles scroll within that area so the "active" column title is visible.

A column should be as wide as the viewport. Swiping between columns will be another ticket.

I'd avoid position: fixed & make the scrollable regions their own overflow:auto element. Flexbox is probably the best way.

Desktop/tablet view:

At some width the columns will be too wide and it'll make sense to give them a fixed width and allow multiple columns to appear on screen.

Here each column has a heading. The top sticky header is down the left-hand side.

After #1, move CSS into head.scss to give us a before-data first render.

Breaks the "immersion" if you load another website within the app chrome, doesn't it?

See #1 for design details.

The active column heading should get a blue underline (it'd be great if there's one element representing this underline & we move/scale it) - this is how the Twitter native app does it.

Clicking on a column heading should pan to that column.

Column swiping (#3) should be reflected on this element. Ideally mid-swipe, see the native Twitter app.

I'm open to ideas for mouse users. Maybe the column heading pan contra to mouse x position during hover. So when the mouse is at the right-hand side the final heading is visible, then clicking it would pan to that column.

This can appear at any point but is likely to appear at page load.

I imagine it sliding in from the top of the page, and dimming everything else. LIke a modal dialog but attached to the top of the viewport. On mobile devices it'll be full width, on larger devices it can be centered.

I think I'm imagining something like Chrome's basic auth box:

…although I'm no designer, so if you have better ideas, go for it.

As for the content of the form, the Tweetdeck one seems sensible:

We don't need to bother catering for old logins.

There's already a view for the login box Login.js and a template login.hbs.

How we do this will depend on #11.

Requirements are:

• Cached tweets should always have a cached avatar
• We mustn't have cached avatars without a cached tweet that needs them

Research best practice for karma/browserify combination. Anyone?

sw.js needs to be built to the root, not static/...

@PhUU has ideas around this, I'll let him give the details.

GIven how tweets trickle in, idb may be a better choice than the cache API.

On mobile we want to do column swiping like the Twitter native app. This should be easy in IE because of http://msdn.microsoft.com/en-us/library/ie/hh772726(v=vs.85).aspx. For other browsers we'll have to make smart use of touch events.

In Chrome, we give you the touchstart and the first touchmove, if neither are preventDefaulted the touchmoves get throttled, so you need to decide if you're going to handle the sideways swipe/pan by the first touchmove.

touch-action: pan-y may help on the columns.

@jakearchibald Could you enable Travis for the repo? I think we should be able to run the tests soooon™!

TD's login flow uses Twitter XAuth, which means we have to deal with 2FA manually. It's documented somewhat.

For the app we built for The Economist [click "Enable" next to enable unsupported devices and then click go to app then "Continue without registering"] we [sometimes] made the offline experience optional (and if you click yes it runs a rudimentary test to try to guess how much space it has available - and will bail if it determines there isn't enough - users can try again via the UI under "My Account").

The reasons are:

1. there are a lot of browsers that request permission from the user to grant offline storage, which range from nasty to hideous and we wanted to give users a little warning that it was about to happen... With apologies to the Mozilla team...
2. On IE the user has the ability to set how much storage it can grant to offline websites - and I think it lets you go as low as 1mb... which just isn't enough for our application to offer any meaningful offline experience. And in those cases we wanted our application to gracefully degrade to being a website, even if it didn't function offline.

So I guess the question I'm asking here is:-

• Are there plans for Chrome/Firefox have any "Would you like to allow this website to install a ServiceWorker?" type UI? [If no then perhaps there is less reason to do this]
• Do we want to architect the app so that it would be easy to make the offline experience optional? (I guess TweetDeck doesn't have as much of a concept of 'drive-by users' in the same way a newspaper has in terms of a number of users who have just come to read a single article)

Since we haven't yet got a working app, I think it's premature to optimize the loading of the user's data.

This would move the start/stop stuff and columnSwiping state out of the component to make it reusable.

As a side note about React, I think it'd better to infer the column swiping state on render, and have the listener trigger a re-render when there's a change.

Populate the columns with REAL LIVE EXCITING DATA. And continue to do so through the life of the page.

I believe @PhUU has better ideas than what Tweetdeck-stable is doing now.

It even told me to go away. How rude.

1. Page requests column structure data from cache
   1. If network data already returned, abort
   2. Render column layout
2. Page requests column structure data from network
   1. Cache response
   2. Render column layout - if you've already rendered a particular column, avoid destroying & recreating it, even if it's changed order

…when not in column 1.

Basically, the swiper needs to do something onresize.

When I npm install, it warns:

npm WARN deprecated [email protected]: use gulp-rimraf instead

And then when I npm start:

/Users/marcosc/Dropbox/repos/marcoscaceres/tweetdeck-prototype/node_modules/gulp-ruby-sass/index.js:101
            var msg = err.trim();
                          ^
TypeError: Object Error: spawn ENOENT has no method 'trim'
    at ChildProcess.<anonymous> (/Users/marcosc/Dropbox/repos/marcoscaceres/tweetdeck-prototype/node_modules/gulp-ruby-sass/index.js:101:18)
    at ChildProcess.emit (events.js:95:17)
    at Process.ChildProcess._handle.onexit (child_process.js:807:12)

npm ERR! [email protected] start: `gulp`
npm ERR! Exit status 8
npm ERR!
npm ERR! Failed at the [email protected] start script.
npm ERR! This is most likely a problem with the tweetdeck-offline-prototype package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     gulp
npm ERR! You can get their info via:
npm ERR!     npm owner ls tweetdeck-offline-prototype
npm ERR! There is likely additional logging output above.
npm ERR! System Darwin 14.0.0
npm ERR! command "node" "/usr/local/bin/npm" "start"
npm ERR! cwd /Users/marcosc/Dropbox/repos/marcoscaceres/tweetdeck-prototype
npm ERR! node -v v0.10.29
npm ERR! npm -v 2.0.0-alpha-5
npm ERR! code ELIFECYCLE
npm ERR!
npm ERR! Additional logging details can be found in:
npm ERR!     /Users/marcosc/Dropbox/repos/marcoscaceres/tweetdeck-prototype/npm-debug.log
npm ERR! not ok code 0
FAIL: 1

If I fix the issue on line 101 above, I still get:

[16:08:12] gulp-ruby-sass: Missing dependencies. Ruby and Sass must be installed and available.

My suspicion is that Ruby is probably too new or something (running on Yosemite 10.10). Tried npm install -g ruby for fun, but didn't help.

Anyway, something to look into at some point. Will see how I get along.

Would need to shim setImmediate for non IE10+ browsers, but might see some small gains, depending on how often this is being used.

Worth considering?

(Thumbs up on the goals for the project too - going full on 'as good as native or as close as possible', even if unachievable right now, is super interesting)

• Load-down button
• Load-up button
• End-to-end cursoring
• In-memory TimelineStore
• In-memory TweetStore
• iDB TimelineStore
• iDB TweetStore
• Infinite scroll
• TimelineStore eviction
• TweetStore eviction
• Gap handling
• Unload offscreen Tweets

I did git clone, npm install, npm start and when going to localhost:8000, I got:

Error: ENOENT, no such file or directory '/tmp/tweetdeck-prototype/www/static/build/css/head.css'

In the console, I see that the gulp "sass" task did start and complete, but the file is indeed missing.

One of the issues I've seen crop up in TD is the compexity introduced by mixing concerns like API requests and storage. tweetdeck.js does this, and it shouldn't.

Currently there's a LoginView, an event-emitting, self-templating View-ish thing. I'd really rather not roll-our-own in this project, and instead go for something that allows us to focus on the hard or unsolved problems: offline and layout using new features.

My suggestion would be React – it's dedicated to the view layer, self-contained and very pleasant to work with.

This includes html, css, js.