We’ll be showing this when a user doesn’t have notifications yet. The text will probably be adjusted in subsequent PRs:
there’s a gt property
nitpick but would prefer
I know this is not your PR but why do we have this enclosing div here ?
just to be sure it’s not forgotten from my other comment, what is this filter=filter doing here ?
why not directly a
That’s a nitpick but I found the verbosity difference between
nothingFound quite unexpected given they only different by a !
I’m not sure we need so many computed properties, maybe use one with
notifications (for model.content) and check length in template. Might be easier to read.
At first glance looks like we’re safe to delete this and
filter=filter from the comment below, but I don’t want to do it in this PR, this is out of scope. Do you want me to clean up this later?
See the comment above.
yes please it would be great
It’s just a first iteration, we’re going to style such pages later, I’m using a standard markup that we use in all similar places (see).
I found the verbosity difference between userDoesNotHaveNotifications and nothingFound quite unexpected given they only different by a !
I don’t think that details of function implementation has something to do with the length and verbosity of the function name. You may have a function with one line of code and another one with 10 lines of code, and it wouldn’t mean that the name of the first function should be 10 times less verbose than the name of the second one. In fact, the first function may have a more verbose name than the second one, and it’s ok. What matters is if the name is accurate, unambiguous, and if you can understand from the name what the function do without reading its implementation.
But I also really dislike that the name
userDoesNotHaveNotifications is so long and verbose. I just can’t come up with a better name. Maybe you have some ideas? When this property returns true, it means that a user haven’t received any notification yet, at all.
and check length in template. Might be easier to read.
I don’t think so. This component has several possible states. What I’m doing is I’m giving these states explicit names which makes the template extremely easy to follow. The very beginning of this video from 30 Day Code Quality challenge is about this.
But again, the name
userDoesNotHaveNotifications isn’t ideal, I understand why you dislike it.
Ok :), will do that later this week.
@jjaffeux I’ve refactored computed properties to make it a bit simpler, could you take a look?