GitHub user benkeen opened a pull request:
https://github.com/apache/couchdb-fauxton/pull/382
Doc Workflow improvements
*** This is just an IDEA. This is not a finished PR. I think the
improvements it makes to the UX is very worthwhile but the
implementation is questionable in places. Intended for discussion
only. ***
_______________________
This PR is part of Doc Workflow to improve the overall
UX of navigating around the UI with respect to the
documents.
Changes:
1. Clicking back/cancel from a full page doc editor no longer
limits the results to 20 on the doc list page.
2. Clicking back to a list of documents from the full page doc
editor now returns you to the last PAGE you were on, and the
SCROLL offset of wherever you were on the page as well.
3. Introduces fauxton/memory.js as a way to store information
across multiple page loads.
Notes:
- Perhaps the functionality in memory.js should be moved to
utils? so app.utils.memory.set(), etc. It could also replace
localStorageGet and localStorageSet: memory.set() and get() would
just take an extra param to specify whether it's getting/setting
local storage or transient JS data.
- itâs missing better tests
- thereâs an existing bug where when you click from one page to
the next it doesnât update the scrollTop to 0 on the scrollable.
Thatâs unrelated to this ticket.
Big flaws:
- The cloudant.pagingcollection.js file change. Why is that a
separate external lib? I ran into serious problem trying to persuade
it to re-initialize on a non-first page and couldnât get around it,
hence the modification to the file. There is a solution around it
by circumventing it in the store, but that felt like an even worse
solution.
- I really donât like having to reference the .scrollable region
(to get + set the scrollTop) within <ResultsScreen />, but I donât
see any other place to do it now we're dropping Backbone views (i.e.
I need a before/afterRender on the routeobject to know when that
element is available in the page)
- generally I find the whole thing a bit hacky, but I love the UX
improvement.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/benkeen/couchdb-fauxton doc-workflow
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/couchdb-fauxton/pull/382.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #382
----
commit ba491edc91d4ac345cf6e0c52cb13b67896db471
Author: Ben Keen <[email protected]>
Date: 2015-04-15T04:56:48Z
Doc Workflow improvements
*** This is just an IDEA. This is not a finished PR. I think the
improvements it makes to the UX is very worthwhile but the
implementation is questionable in places. Intended for discussion
only. ***
_______________________
This PR is part of Doc Workflow to improve the overall
UX of navigating around the UI with respect to the
documents.
Changes:
1. Clicking back/cancel from a full page doc editor no longer
limits the results to 20 on the doc list page.
2. Clicking back to a list of documents from the full page doc
editor now returns you to the last PAGE you were on, and the
SCROLL offset of wherever you were on the page as well.
3. Introduces fauxton/memory.js as a way to store information
across multiple page loads.
Notes:
- Perhaps the functionality in memory.js should be moved to
utils? so app.utils.memory.set(), etc. It could also replace
localStorageGet and localStorageSet: memory.set() and get() would
just take an extra param to specify whether it's getting/setting
local storage or transient JS data.
- itâs missing better tests
- thereâs an existing bug where when you click from one page to
the next it doesnât update the scrollTop to 0 on the scrollable.
Thatâs unrelated to this ticket.
Big flaws:
- The cloudant.pagingcollection.js file change. Why is that a
separate external lib? I ran into serious problem trying to persuade
it to re-initialize on a non-first page and couldnât get around it,
hence the modification to the file. There is a solution around it
by circumventing it in the store, but that felt like an even worse
solution.
- I really donât like having to reference the .scrollable region
(to get + set the scrollTop) within <ResultsScreen />, but I donât
see any other place to do it now we're dropping Backbone views (i.e.
I need a before/afterRender on the routeobject to know when that
element is available in the page)
- generally I find the whole thing a bit hacky, but I love the UX
improvement.
----
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
