Task Preview Functionality and Bug Fixed Aesthetics for the Utopian V2 Frontend

in utopian-io •  4 months ago



Bug Fixes

In this set of pull requests, I fixed small bug with regards to the Icons on the create page.

  • Fixed the Icon color of the Social and ideas contribution categories.


Solution to this Bug

The solution for this issue was to create a set of CSS selectors for the ideas and social categories inside of the global style sheet called colors.styl. After which, I then fixed the color by assigning the global $social and $ideas colors to their respective selectors. The image above shows the bugged colors and the image below shows the fixed colors. This bug was resolved with this commit.


New Features

In these Pull Requests, I added a number of features pertaining to the task request preview components and the user profile component.

  • Added the ability to hide elements in the side box of the user profile in response to the information filled out by the user. If the user does not have a location or a website attached to their account, then those boxes will simply not show. If the user does not have an "About Me Biography" filled out then this box will display the text, "There is no information about the user".
  • Added a color border to the top of the task request previews. These colors are based on their corresponding categories. For instance, the copywriting category and the task-copywriting request category share the same color for this border.

  • Added icons to the task request previews which correspond with the existing icons of their counterpart contribution categories. As an example, the development contribution icon will appear on the task-development request category as well.

  • Added task titles for the task request previews which appear in the various places of the frontend. This makes the Task request previews more in line with the Category contribution previews.


Implementing the Features

To make the user profile reactive based on the information being passed into it, I created some simple Vue logic inside of the pug template of the profile component. For the location and website blocks, I built in a set of v-if statements to check to see if the associated data for the user exists. Since the v-if statement is lazily evaluated, if the data exists then the item is parsed and rendered as HTML, otherwise, the components are not parsed and rendered. For the About Me block, I build a set of v-if and v-else statements to allow the block to display one element or the other in response to the user biography information. Either the user's biography appears or the placeholder text appears. This was done in this commit with minor cleanup and comments added in future commits.

The task features required that I first build an array of strings which contained all of the task categories. I then set about creating a new field called _tasks which is attached to the global post object. Also, I amended the _visibile_tags field in the post object so that the proper tasks tags would be consumed and then placed into the _tasks field for global use. I then created a set of Css selectors which followed the existing contribution category selectors style and changed them to account for these new task classes. These additions can be seen in this commit.

To make the titles, colors and icons of the tasks visible inside of the post-preview Vue component, I then altered the pug template for this component. I built a v-if statement to check to see if the post._task field existed on incoming post object. The title, color and icon would not show if this field was null or undefined; however, if it does exist then the following part of the template would be parsed and rendered.

As a side note, I did forget that in JavaScript a variable/field could be considered undefined rather then just null. As a result of this I encountered an error with my initial logic and tried to fix it by creating more complex logic. Once I had realized my mistake, I decided to instead create a filter function which would then parse the incoming post._task string and alter it to suit the needs of the template. I then generalized the filter function to also parse the post._category field. This function is bound to the q-icon component which in turn generates the proper class for the icon. The generalized filter function can be found in this commit

To get the top color of the post-preview component to show properly, I added a ternary operator to the top of the opening q-item class which checks to see if the post._category field exists for the incoming post. If this field does exist then it uses the post._category string as the class otherwise it uses the post._task class. By doing things this way, we have a clear separation between the previews which belong to tasks and the ones which belong to category contributions. This was done in this commit

Pull requests referenced in this contribution: here and here

GitHub Account


Authors get paid when people like you upvote their post.
If you enjoyed what you read here, create your account today and start earning FREE STEEM!
Sort Order:  

Thanks for the contribution, @tensor! Great to see you are helping out on v2.utopian.io!

Some feedback:

  • Please wait until a PR is merged before submitting a contribution about it (this PR is still open)
  • I don't know if this is something you have all agreed on, but the amount of comments feel a little much - you are practically adding comments for every line of code. Also, don't think stuff like this is really necessary
// filters
filters: {
  • Since the voting % is exponential now it's more beneficial for you to submit a heftier and "more significant" chunk of code as a contribution as it will result in you being rewarded more for your work (e.g. combining your previous two contributions into one)
  • Great job on implementing everything and writing the contribution itself. It was very pleasant to read and to review - can't wait to see more!

Your contribution has been evaluated according to Utopian policies and guidelines, as well as a predefined set of questions pertaining to the category.

To view those questions and the relevant answers related to your post, click here.

Need help? Write a ticket on https://support.utopian.io/.
Chat with us on Discord.


Hey @amosbastian,

Thank you for taking the time to review my contribution and leave feedback for me. I would like to clarify a few things with regards to your feedback and nitpick on one small thing that seems a bit odd.

I joined the development team in a rather small capacity because I am otherwise disposed with my day-job. I can't contribute as much as the other team members (or at least, my contributions aren't as large). I have mainly focused on closing all of the smaller and less critical issues that the other developers are too busy to deal with. I still do have the same authority as the other developers and I can merge PRs but I have chosen not to in lieu of getting the other devs to review my work first. This is generally what I do when I am not the lead developer on a project, even if I am a more senior developer. It's easier to work on a project when egos are not involved as I am sure you know from being a dev yourself.

Initially I wasn't going to include the open PR in this contribution but I eventually chose to do so because it contained pieces of code which cleaned up the overall developer story of the features I was implementing in the first PR. Also, so as not to confuse the readers and reviewers of this contribution, I added a few of the features from that PR to the contribution. The other developers have enough trust in my skill and they wouldn't think much of me merging this PR but I choose not to do this. That courtesy aside, I am 100% confident that this PR will be merged without issue. I figured it would be fine in that regard to refer to it in the contribution. Also, I know that come week (aka tomorrow onward), I will probably have less time to write contributions when compared to yesterday. I do still understand your concern, but as a official contributor on the project; I feel that it might be a little misplaced.

On my own projects and on Projects where I am the lead, I usually write a few large and very descriptive comments to help describe the API and functionality of the program. These comments typically accompany Functions and Classes that a user or a dev might interface with. They also appear on critical code and on code that might be temporary, unimplemented and could potentially be changed by myself or the other members. I am not the lead on this project though so I chose to follow the existing idiom for writing comments on this project. There is a bit of logic in doing so because very few of the devs on the team are native English speakers and many of the variable and function names in this project are not as descriptive as they could be. This isn't really my decision; it's just how the other developers have chosen to do things for now ( I do suspect that when the code becomes more solid, the comments/documentation will grow in size as well).

I did consider writing one single contribution which would encompass my last contribution and this contribution but I found that the two contributions has distinct topics which were hard to reconcile. One is about the internal logic of the Markdown parser and the Regular Expressions that is uses and the other one is about aesthetic features and bugs. I just couldn't find a good way to combine the two topics and make a coherent article while still giving the topics some amount of description. I assumed that the articles and the general journey/story held a decent amount of weight in this category because of my experience in the Video Tutorials category. I now suspect that this is not the case.

As for my little nitpick: despite my last contribution being more complex and technical, the amount of code that I wrote for it was far less than the amount of code that was written for this contribution. Yet, for question number three in the questionnaire, it says that this contribution has less "volume of work" compared to the last one. This seems a little backwards to me considering the "volume of code" written is objectively more than what was written in the last contribution. I am not sure what the logic here is and a little clarification could help in this regard. It's really not the biggest deal but I did notice this little inconsistency between the two articles.

Thank you again,



Regarding the PR it's not a big deal as I also know it will be merged, however as it's something that it's in our guidelines it should still be kept in mind.

As for the amount of work (does not mean lines of code); this is highly subjective and based on each moderator's experience. More than likely the increased complexity and technicality of your previous contribution was taken into account when reviewing it.

I do not know if you have seen @gregory.latinier's great guide on development contributions, but I would definitely recommend checking it out.


Thank you for the follow up. If there is another development contribution from this repository (which I suspect there will not be), then I will try to choose less "trivial" code.

Excellent work, I was surprised to see that the vue.js was used while creating the Utopian V2.


When I first started developing on the front-end I was a bit surprised too, but mainly because they were using JavaScript rather then TypeScript with Vue2. The primary technologies for the front-end are Vue2, Vuex, Quasar, dexie and Firebase. We are also using Pug and Stylus.

Congratulations! Your post has been selected as a daily Steemit truffle! It is listed on rank 23 of all contributions awarded today. You can find the TOP DAILY TRUFFLE PICKS HERE.

I upvoted your contribution because to my mind your post is at least 12 SBD worth and should receive 58 votes. It's now up to the lovely Steemit community to make this come true.

I am TrufflePig, an Artificial Intelligence Bot that helps minnows and content curators using Machine Learning. If you are curious how I select content, you can find an explanation here!

Have a nice day and sincerely yours,


Hey @tensor
Thanks for contributing on Utopian.
We’re already looking forward to your next contribution!

Want to chat? Join us on Discord https://discord.gg/h52nFrV.

Vote for Utopian Witness!