karrot-dev / karrot-frontend

Mirror of https://codeberg.org/karrot/karrot-frontend

karrot

Start a group, become a community

Karrot is a free and open-source tool for grassroots initiatives and groups of people that want to coordinate face-to-face activities on a local, autonomous and voluntary basis.

It is designed in ways to enable community-building and support a more transparent, democratic and participatory governance of your group.

This is the frontend repository, i.e. the browser-side software that powers karrot.world. Have a look at our server-side code at karrot-backend, and the Karrot Documentation too!

Features

• manage information about places 🍎
• schedule both one-time and recurring activities 📆
• gather feedback about activities 🔍
• talk with users before they become group members ➕
• let newcomers show their trust and get involved 💡
• communicate with your team via group, place, activity, and private chats 💬
• handle team member conflicts via score voting ⭐
• receive real-time notifications via our Android app, e-mail, and web browser push notifications 📢
• use karrot in your preferred language 🌐
• upload a group logo and customize your public information 📷

Foodsaving worldwide

The foodsaving worldwide team provides additional resources to build up foodsaving, e.g. an infopage on foodsaving.world, where all the intel is gathered.

Development goals

Our current development goals are prioritized and written down in our elaborate roadmap.

Releases

For a quick overview of recent changes and our version history have a look at our change log file.

Translation

We are using Transifex to provide karrot in many languages. To help us with translation, please create an account and apply for the karrot group.

After selecting your target language and choosing the resource file, go ahead to start translating!

Setup

Make sure you have the following packages: Node.js, yarn and npm

To clone and install:

git clone https://github.com/karrot-dev/karrot-frontend.git
cd karrot-frontend
yarn

To run the local dev server:

yarn dev

To lint and run the tests:

yarn lint
yarn test

If you want to use an eslint plugin for your editor, please keep in mind that you either have to install all eslint plugins listed in package.json globally or you run yarn install. Otherwise your eslint plugin may not work.

Tip: use DEBUG_PRINT_LIMIT=999999999 yarn test to see ALL the output.

Start contributing?

We have a forum for Karrot developers and users at https://community.karrot.world.

If you are interested in contributing, check out our onboarding guide.

The most important dev information is written down in our contribution guidelines.

The backend is developed to support this frontend. If you find a bug or miss something in the API, please file an issue in the backend repository.

Contributors

Significant contributors to karrot:

Tilmann Becker 💻 🤔 🚇 👀 ⚠️ 💬	Nick Sellen 💻 📖 🚇 👀 ⚠️	Janina Abels 🤔 🐛 💬 💻 🌍	D0nPiano 🎨 💻 🤔	Lukas Gebhard 💻 🤔 👀 📖	mrkvon 💻 🤔
taistadam 📝 💻 🎨 🤔 🌍	Ines Dorian Gütt 💻 📖	Marie Dedikova 💻 📖	Andreas Langecker 💻 🎨 🤔	djembejohn 💻 🤔	Matthias Larisch 💻
pogopaule 💻 🤔	Thiago Mendes 💻 🌍	Xaph 💻	lwm 💻	Bruno MC 🐛 🔍 🤔

This project follows the all-contributors specification.

Attribution

Karrot is built with open-source software. Here are some of them:

• Django
• Django REST framework
• VueJS + vue-query
• Quasar Framework
• Twemoji

karrot-frontend's Issues

Working Login page

Create a working login page plus a home screen showed when logging in was successful.
Use the designs of material-proposal.
Edit: Lacking of time, so home will be implemented in a seperate issue; Default home screen of ng6 starter is implemented by now

Add generator for services

Test for user service

This issue is just pro forma. I'm working on an test for the user data service (app/common/user)

Contribution Guidelines

Remove use of ES6 Promise

ES6 Promise is not usable in angularjs, as $digest and $httpBackend (in testing) make use of internally fiddling with promise resolution. You can use $q service instead.

Decision on service methods

I've seen different approaches by @Sneezoo @D0nPiano and me. Would like to have one style.

1. get(params) where params can either be {id: 1} or a filter parameter {group: 15}.
2. same as above, but where get() also lists all entries
3. additional list() method, sometimes called groups() or the respective name
4. only getById(id) and get(params) methods with optional filtering

I would be in favour of (4), it seems clearer to me.

Also, should we always use the one-object style for parameter passing?
save(id, update) vs save(obj) with obj = {id} + {update}
At least for a save request, the id is not expected by the server as payload, would currently throw BAD_REQUEST, so would need to be filtered out before sending.

I would be in favour of save(id, update).

This touches #46 #47 and surely some other contributions.

nest stores into groups?

How i imagine the hierarchy: Page -> Group -> Store
shouldn't the url represent this (i.e. /#!/Berlin/store/15) and the components as well?

in #84 there is currently a discussion about how to shape the data flow.
The reactway would be having the active groupId in home and passing it down all the way to groupMenu & groupDetails

right now the hierachy seems really chaotic and randomly, so we should create more mockups! :)

Update CONTRIBUTE.md

See #82 for a TODO list

@D0nPiano @nicksellen @tiltec @Xbaal Add things please ;-)

Add currentGroup to group service

Implement a way to get and set the current group. If nothing is selected yet, just return any group the user is member of.

Create Pickups

Add functionality to create Pickups.

Pickuplist Component

Creating a PickupList component, that is able to display pickups, let the user sort & filter pickups, and leave / join pickup dates

Dependant on #36 and #37.

StoreList Component

List of Stores

Options:

• bool showEdit (show edit button next to store name)
• stores (either by Id or complete)
• callback (optional, default: open StorePage)

Rewrite tests to use chai-as-promised

I recently introduced chai-as-promised, which allows you to handle promises in tests more easily.
We should rewrite tests, that would benefit from this.

Remove wrapper from service generator

I think the wrapper adds more complexity than necessary at the current state of the project. I would make sense to add it back in certain cases, but not generally.

Some services might also be non Com services, so always having a Com wrapper seems to be excessive.

Therefore, I'd remove the wrapper in generator code.

chai-as-promised change needed?

After merging #57 I just found this:
https://github.com/vlkosinov/karma-chai-as-promised#usage

It states, that the order of the framework declaration in the karma config makes a difference.
I tested the functionality of chai-as-promised and it worked, so it might not be of siginificance.

So this issue might be void, it's more like a reminder, that there could be caused some problems.
And as well a proposition to not use karma-chai-plugins, but karma-chai-as-promised, which is just a smaller set of plugins (only the one i included).

Tests for component Login

Currently it's using the generated default.

nstest1

just testing

Initiation period for users a.k.a introductory pickups

Foodsharing initiatives in Nantes, Warszawa and generally in Germany (foodsharing.de) use the method of introductory pickups to get new foodsavers familiar with the special circumstances of stores.

For now, I would suggest that only approved members get access to the group (by restricting the join capabilities). Therefore, all members of the group will be able to pick up at all stores.

In the future, it takes a lot of work to manage the people who haven't completed the initiation yet (especially if it is per store), so I suggest the following feature idea: initiation.
A new group member can see the pickups of the groups, and join them together with another person (who is already initiated). After one guided pickup, the new member can also pickup food alone at this store. For each store, another initiation is required. You can never lose the initiation status.

What do you think?

Topbar

component topbar, containing:

• button to home
• button for slide menu, showed only on mobile devices
• searchbox, hidden on small mobile devices
• conversations button
• profile settings button
• logout button

Logout directive

It is essential to make authentication fully testable.
It will be added to the top bar of the home route logging out the user on clicking.

Is it ok if any group member performs any action or do we need hierarchies?

Currently there is no hierarchy, all group members have the same powers: edit group, edit/delete stores, edit/delete pickup dates for all stores in the group.
Additionally, all users of the website can join all groups.

To prevent potential abuse or mistakes, I thought of the following:

• have history tracking, showing who changed what (basically surveillance)
• offer undo features (quite complicated in the backend)
• require approval from existing members to join the group
• disable some operations altogether (groups can't be deleted, you can only leave, won't be shown when nobody is in it or when is there no activity in x months, no kicking of members)
• have admins that can handle the critical operations like deleting/modifying (well.. who deserves to be admin?)
• have a full-blown voting/syscon builtin that can handle serious topics like deleting the group or kicking a member out (horribly complex)

What do you think is a good compromise between resilience, self-empowerment and coding time?
I will also invite non-coders from Slack :D

Rename of "groups" component

I don't really like the name "groups" for the groupContainer anymore. Thinking of just renaming it to "groupContainer" and now creating a "storeContainer" for the store page - and objections? Or other naming ideas?

Add better description and setup instructions to README.md

• npm install etc
• backend information (dev.yunity.org live backend, local backend)
• Development process (could also go in CONTRIBUTE.md?)

Service Generator creates Components instead

Running gulp component --name <service> --template service --parent ../common creates a component ("_component") at the moment.

Cache response for store details

Currently, showing the groupDetail page fires duplicate requests to the backend, one for each pickup in the list.

This is the code in question:
https://github.com/yunity/foodsaving-frontend/blob/master/client/app/components/_pickupList/pickupList.controller.js#L37

Could be optimized by caching the promises or the resolved promises in an object.

Data services as factories and to return promises

According to this angular style guide, factories should be used instead of services for consistency.

Also, data services should return promises instead of resolving them.

@Sneezoo: what is your opinion on this?
Given my total inexperience as angular dev, I'd like to orient myself on the most widely spread style if it makes sense for you.

Group Container

Component to list all groups a user is added to.
It depends on #19

Extend group service to save active group

The user can be part of multiple groups, but only one is shown. Save the active group to the group service.

Default: first group of the user

Signup flow

As @Xbaal mentioned, I removed the password repeat check. I did it out of personal preference. I'm very happy that many modern websites don't use it anymore, and I never had a problem with mistyped passwords. Plus, many browsers save passwords.
But I have more on my mind, that's why I'm creating this issue.

My proposal for a signup form: just enter your mail. Then the user already gets access to the page and can look around. The user also gets a mail to verify his address and clicks on a link, where he can set his password and optional first+last name. (This is inspired by Slack signup)

When we have users, I would introduce some logging how many users mistyped their passwords on the first try and use the password recovery option.

Further resources:

• Generally I prefer SSO solutions like OpenID, including facebook and google auth
• https://ux.stackexchange.com/users/signup is a nice example of preferring SSO providers, but also allowing a 1-step signup with 3 input fields
• People argue here if optional unmasking of the password increases UX

Store Service

Pretty much like the group service, except with stores.

Pickup-Dates Service

A service to get pickup dates by groups and stores, to add new pickups and for users to join / leave existing ones.

Proposal: use Restangular instead of $http in services

Restangular seems to be quite popular (over 7000 stars on GitHub) and promises to remove a lot of redundancy from the service definitions.
Also, it seems to be easy to enable site-wide caching.

I'm collecting more upsides/downsides. Obviously, the http part seems to be the easy part of writing a webapp, and I think I could simplify the code even more.

Remove base service, create validation service

base superclass is collecting random code, better separate it into individual services.

Different purposes of GroupDetail and StoreDetail

It appears to me that @D0nPiano designed PickupList to be usable in GroupDetail, as well as a future StoreDetail page.
The PickupList has the additional parameter showDetail, which defaults to date, but is currently only used with store.

The bigger question to me is how different the GroupDetail and StoreDetail pages will be?

My view on this:

GroupDetail

Central page for a group, with the upcoming empty pickup slots and pickups slots where the user entered himself (=tasks to do, tasks that I promised to do). A list of all users, possibility to send messages to them (to discuss), a map of all stores in the group (to discuss)

In future, it could show recent updates to store descriptions and to posts in team chats (not implemented yet)

StoreDetail

Show and edit the name & description, show all pickups (also completely filled ones), add new pickups, show pickup history (to discuss)

In future, it could show a team chat and let you post in it (not implemented yet).

Summary

The different purpose of those could lead to different designs, e.g. the list of pickups in the GroupDetail may be simplified, without the filtering and sorting options, whereas the StoreDetail page is much more complex, as should mostly used be users (think store managers) who need these functions anyway.

Does not build/run

On a fresh install on master branch there are two errors during webpack build:

ERROR in ./client/app/app.config.js
Module build failed: SyntaxError: /tmp/foo/yunity-angular/client/app/app.config.js: Unexpected token (16:6)
  14 |       abstract: true,
  15 |       url: '/'
> 16 |       data: {
     |       ^
  17 |         loggedIn: true
  18 |       }
  19 |     })

ERROR in ./client/app/common/authentication/authentication.service.js
Module build failed: SyntaxError: /tmp/foo/yunity-angular/client/app/common/authentication/authentication.service.js: 'this' is not allowed before super()
  10 |   constructor($rootScope, $http, User) {
  11 |     'ngInject';
> 12 |     this.$rootScope=$rootScope;
     |     ^
  13 |     this.$http=$http;
  14 |     this._credentials = {};
  15 |     this.isLoggedIn=false;

Error handling in login form

I basically removed the error handling at my last reworking. I should add it back in again, using some nice angular forms support.

https://github.com/yunity/foodsaving-frontend/blob/master/client/app/components/login/login.controller.js#L19

Add translation support to the frontend

As we are building a platform for worldwide usage and not everybody speaks English, translation support is paramount.

I looked a bit around and found an angular package:
https://github.com/angular-translate/angular-translate
Should we use it? There doesn't seem to be out-of-box support for this in angular. It seems quite simple to use, just feed it with an object of translation strings:
https://angular-translate.github.io/

There's also another package, but much less active:
https://github.com/rubenv/angular-gettext

Simplified login check handling

The code to check if the user is logged in is very complicated [1]. It'd be much simpler if auth.update() returned a promise, and was used in a route resolve function [2].

An alternative more general implementation to the route resolve functions would be to add an "auth required" property to each route that requires it, and handle the general case from the authentication module using route state transitions.

[1] https://github.com/yunity/yunity-angular/blob/master/client/app/components/home/home.hook.js
[2] https://github.com/angular-ui/ui-router/wiki#resolve

Dialog Service for Create Panels

Create a Dialog service, that makes opening Angular panels more pretty.

Panels:
https://material.angularjs.org/1.1.1/demo/panel

Clean up User service

The User Service is quite messed up.

UserList Component

A List of Users / Members
Options:

• Callback (optional, default: open UserPage)
• Users (either by Id or complete)

Group Service

Service for yunity groups.
Look up the existing authentication or user services for style.

Tests for Signup

Remove usages of first & last name

display_name is more than enough right now, let's not depend on first & last name (they are optional in the backend)

I would add them later if needed (e.g. for legal reasons).

Include login.form.js in login controller

Currently, the login functionality is provided by loginForm.
Rewrite it to include it in the controller and use ngClick.

After login, redirect user to his active group page

This should be the homepage for now, the home component is currently not need.
URL could still be /group/
Depends on #76 and maybe store the active group in localstorage. If localstorage is empty, just use first group that comes from server (will be only one for most use cases)

Rewrite Service Methods

Since the decision on service methods seems to be done, We shall rewrite them like:

• get(id) => get one object
• list() => list all objects
• listByXyzId(id) => list all objects filtered by Xyz's id
• create(object) => create an object
• save(object) => save changes for an object; to make the backend happy id is going to be removed before sending using PATCH
• delete(id) => delete an object by id
• search(string) => search for an object by string

Are you, @tiltec working on it? Otherwise I'd probably asign myself :)

Store Component

Store component, that displays a store name & description with it's pickups

Register hook factory in angular

At the moment the hook factory is loaded as an ES6 module, it would be better to load it via angular system.

I would suggest looking into defining a provider, such that the hooks can be registered in a config block.

Tests for component Home