There's another link to undraw but are there any more places to find stuff like this? Paid or free? I was recently looking for an svg shape library purely for decoration but couldn't find anything.
The downside is, of course, the wildly varying style and quality, which means that finding the good images can require sifting through lower-quality content. But at least to me, that's often more useful than a comparatively tiny selection of consistently high quality art which probably just isn't going to have what I'm looking for. They also are using straightforward CC0 terms, which is always a plus compared to custom licenses.
Do you store all UI state in redux as well as all 'resource state'? Phrased as an example... If you store a JSON object that can be edited in your store do you also store a Boolean value for whether the dialog is open that can be used for editing that JSON object?
I agree with that logic, I think I've encountered every one of those cases.
That makes me see that there isn't a "god" object like the article calls it, that holds all of the app state. There's the root state shared throughout the app, and then each page or component can have its own encapsulated state.
Ideally I like to also keep page- or component-specific state+actions decoupled from their views, functional and testable independently - but often I start/keep them in the component class (and maybe soon hooks).
You can also apply the command pattern in some cases and store the undo redo state globally.this at the global store can be generic and the previous specific state will be part of the saved commands. (More applicable to SPAs).
Hmm, typically, I do store "UI state" (or parts of it) in the top app state if that UI state is shared among pages/routes. In your example, if I want that dialog state to be "persistent" - say, the user goes to another route then comes back, if the dialog state should be kept. Otherwise, I store them in the route component's state, which gets created anew every time.
But your question makes me think, if I store any UI state in the app state, have I really decoupled state and view? I'd say yes - since I'd be able to build and test UI state and actions, independent from the view.
Well, at least theoretically, the way I organize state management allows me to pull in "slices" of app state/actions (or even moved into shared libs/modules), to compose a smaller subset for an API or CLI. So the latter can choose to not include any of the UI-related state.
In practice I haven't used it so much, but I like the idea of treating the UI as just another render target / consumer of app state/actions. It enables "remote control" of the app logic, makes testing simpler, and allows reuse for various interfaces like CLI, API, maybe React Native too.
I've been playing around switching web-apps and other user programs between devices on a single-ususer facing kubernetes system. Part of that relies on all state being sent to the server for distribution if a device switch happens.
I also have played around with a wrapper functions and that can bubble any callback/hook up to the data for further processing. The client no longer worries about sending actions. The server spys on client actions and performs actions on their behalf.
I dont do this repeating class business but CSS Tricks 'css guidelines' web page says that when you do : '.collection li', it first searches through the page for all 'li's then wittles it down to the ones within the correct parent. Essentially that css selectors work from right to left. So I guess the idea is that classing up the li elements within a parent may be marginally quicker? I have never bothered though. Does anyone know more about this?
Modern browsers do their best to optimize typical use-cases for CSS selectors and .collection li for sure will be handled optimally. You shouldn't worry about CSS selector performance unless you have to provide good performance for very old browsers or hit specific performance problem. Optimize for humans, not for computers.
This is true, actually. They are read from right-to-left. I'm not sure how much extra resources are expended searching this way opposed to the other, though my guess would be the same as yours. It may be worth a benchmark?
It used to be the issue in the "old browsers", modern browsers optimize the css query selectors to a very high extent, so users probably won't see a difference on any real web page / app
In my experience AJAX is used a lot to do the opposite of 'loading down' a site. Often used for staggering page load - preventing a huge download time at first page load and means one page sites can be possible, with many images even, and not take 2 minutes to download on mobile.
Why would your animosity be targeted at the language and the developers.
The market wants what the market wants. Surely most of the time, in most cases, it is the client that signs off a design and a developer follows the brief?
The post you had here before you edited was completely nonsensical.
A UX post, on how a site should prevent users from cancelling to benefit the website, at the expense of the user.
That is the opposite of a good UX.
Here is some 'User pseudo-psychology' for you... Having your blog titles take up more than half the vertical space of my browser (when it is full screen) stops me reading your writing.
Here's some UX for you - the user owes you nothing.
Sure have an optional form or field for cancellations but 5 minutes? How is this beneficial for anyone?
So, it's a free product - they will just never cancel their account and you will have inactive users sitting there. Who is this good for?
So it's a paid product - they will cancel their account and tell everyone about the ridiculously long winded process they had to go through to cancel it.
... or they'll just dispute the recurring credit card charges for your paid product, and you'll get your merchant account frozen after a few "cancellations".
We can argue over whether or not the original suggestion constitutes fraud, but the credit card companies will definitely treat it as fraud.
Recently implemented snap.js on a site with the ability to drag the menu from the left as well as press the 'hamburger' button. On iOS I found that dragging from the edge of the screen leads to a hit and miss situation where the user may sometimes open the nav drawer but may also sometimes go 'back' to the previous page. How are people 'doing' navigation right now? I always liked the sliding navs on mobile sites, but where should I have the drag box. The bottom of the screen?
I would have it take up the bottom 80-90% of the page. For me, and most people I see using smartphones, you could get away with a drag box that takes up only the bottom 30% or so (the most comfortable place to perform such a gesture with one's thumb), but it makes sense to handle the edge cases. Also, if someone tries to trigger that gesture and miss, the default behavior is going to be "try it again, but starting closer to the edge and higher up".
In the case of having such a large drag box how should I be ensuring the user can still interact with the content of the page. E.g make sure the hitbox isnt over the top of links and that users can still highlight text etc?
I recommend using the excellent Hammer.js[0] library to pick up swipes (since that's the gesture you're looking for). I've put together a small proof-of-concept here[1]. Try it out on your phone.
Alternatively, if you wanted to have some slick dragging action (so that a user could swipe a little, and control the rate at which the menu drawer opens), you could put a smaller (maybe 10-20% width) dragbox along the left-hand-side of the screen, and keep your selectable content to the right of that.
